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Preface 



The purpose of this publication is to enable pro- 
grammers to avail themselves of the many advantages 
offered by the 1410 Input/Output Control System. 
To this end, the text explains the functions and use 
of the iocs macro-instructions and the necessary 
diocs, dtf, and da entries. 

It is assumed that the reader is thoroughly familiar 
with the following ibm publications : 

IBM 1410 Principles of Operation, Form A22-0526 

IBM 1410 Autocoder, Form C28-0309 

Programs incorporating the ibm 1410 Input/Output 
Control System can be generated by the 1410 Tape 
Autocoder Processor, which requires the following 
minimum machine configuration: 

20,000 positions of core storage 

4 ibm 729 ii, 729 iv or 7330 Magnetic Tape Units 

( may be intermixed ) 
1 ibm 1402 Card Read Punch, Model 2 
1 ibm 1403 Printer, Model 2 



o 
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Major Revision (May 1965) 

This publication is a major revision of IBM 1410 Input /Output 
Control System for Card and Tape Systems, Form C28-0334-1; 
the revision obsoletes that publication and associated Technical 
Newsletter N27-1208. Changes not previously published are in- 
dicated by a vertical bar at the left of the corrected text or by 
a bullet ( • ) at the left of the caption of the revised illustrations. 



Gopks of this and other ibm publications can be obtained through ibm Branch Offices. 

Address comments concerning the contents of this publication to: 

IBM Corporation, Programming Systems Publications, Department 637, Neighborhood Road, Kingston, New York 12401 



o 



Contents 



Basic Principles of the 1410 IOCS 5 

Advantages of the 1410 iocs 5 

Available Input/Output Routines 5 

iocs Check List 5 

Assembly of Programs Using iocs 5 

Use of the 1410 IOCS 7 



The 22 Macro-Instructions 

OPEN 

CLOSE 

CLOSD 

GET 

PUT 



STACK 
SKIP __ 



7 

7 

8 

8 

8 

9 

10 

11 

CONSL 1 1 

RTLBL 12 

WTLBL 1 2 

RELSE 12 

FEORL 13 

CHKPT 1 3 

RDLIN 14 

IOBSP 15 

IORWD 1 5 

IORWU 15 

IOWTM 15 

PSTAC 15 

RTAPE 16 



The DIOCS Entries 



19 



General Format 19 



19 
19 
19 
20 
20 
20 
21 
21 
21 
21 

READERROR 22 

PRIORITY 23 

CHECKPOINT 23 

CHANCHANGE 24 

INQUIRY 24 

urrequest 24 

ur2request 24 



List of diocs Entries __ 
The diocs Header Line 

diocsorg 

features 

CHANX 

LABELDEF 

ALTDRIVE 

EXITS 

COUNTS 

RWDOPTION 



The DTF Entries - 

General Format 



List of dtf Entries „__. 
The dtf Header Line . 



26 
26 
26 
26 



FILETYPE 

PREFIX 

MODEPAR 

CHANDRIVE _ 

CARDPOC 

ALTTAPE 

RECFORM 

SIZEREC 

PADDING 

BLOCKSIZE _„ 

IOAREAS 

WORKAREA ___ 

INDEXREG 

PRIORITY 

EOFADDR 

WLRADDR 

TOTALS 

TYPELABEL _ 
CHECKLABEL 

HEADER 

SERIALNUM _ 

REELSEQ 

REWIND 



26 
27 

27 
28 
28 
28 
29 
30 
30 
31 
31 
32 
32 
32 
32 
32 
33 
33 
33 
35 
36 
36 
36 
36 
37 
37 
37 
37 
37 
37 
37 



The Eight iocs Exits 

exIaddr 

ex2addr 

ex3addr 

ex4addr 

ex5addr 

ex6addr 

ex7addr 

ex8addr 37 

varbuild 37 

scheduler 38 

DA (Define Area) Entries Needed to Support the 

IOCS 38 

Input Areas 38 

Output Areas 40 

Work Areas 41 



Additional Information for Programmers 
Error Treatment 

Invalid Tapes 



Record Additions and Deletions __. 
Size of the iocs Routines 



42 
42 
42 
42 
42 

43 
43 
43 

iocs Diagnostic Messages 46 

User-Coded 1402 and 1403 Input/Output Instruc- 
tions 46 

Index 47 



Operating Times for get and put Macro-Instruc- 
tions 

Priority Interrupt Routine Time 

Tape File Tables 



o 



o 



o 



o 



Basic Principles of the 1410 IOCS 



Advantages of the 1410 IOSC 

The ibm 1410 Input/Output Control System (here- 
after referred to as the iocs) is a set of macro-instruc- 
tions and subroutines that schedule and execute the 
efficient transfer of data from external storage to core 
storage, and from core storage to external storage or 
an on-line output device. The use of these macro-in- 
structions and subroutines frees the programmer from 
coding his own input/output routines for unit record 
devices (e. g., the 1402 Card Read Punch and the 
1403 Printer) and magnetic tape.* 

Merely by using get, put, and related macro-in- 
structions, the user can handle the input and output 
of logical records. In addition to performing input/ 
output operations, the iocs automatically blocks and 
deblocks records, provides the coding required to 
overlap read/write operations with processing, if the 
1410 is equipped with the Overlap and Priority 
special features, and allows a limited amount of inter- 
rupt programming. 

Since Input/Output routines constitute approxi- 
mately half the average program, the iocs offers users 
substantial savings in the area of program writing and 
testing. 

Available Input/Output Routines 

The ibm 1410 iocs provides the programmer with 
tested routines which will automatically: 

Read or write records or groups of records. 

Block or deblock records. 

Schedule the overlapping of read, write, and proc- 
essing operations — if the 1410 has the Overlap 
and Priority special features. 

Check for read and write errors. 

Correct correctable errors. 

Check or write tape labels. 

Write checkpoint records. 

Check end-of-reel conditions. 

IOCS Check List 

For each program which is to utilize the iocs, the 
programmer must: 



* Special sections of the Input/ Output Control System for ibm 
1405 Disk Storage and ibm 1301 Disk Storage can be incorpo- 
rated into the ibm 1410 iocs. See IBM 1410 Input /Output Con- 
trol System for 1301 Disk Storage, Form J28-0251. 



1. Write one set of diocs (Define iocs) statements. 

2. Write one set of dtf (Define The File) state- 
ments for each file used by his program. ( A file is 
a collection of records which may be arranged 
in different ways. ) 

3. Write proper da (Define Area) statements for 
each area used by iocs. 

The diocs and dtf entries are punched into ibm 
cards and must precede the source program during 
assembly ( Figure 1 ) . 

Assembly of Programs Using IOCS 

CHANNEL SCHEDULER 

Before assembling a program using the joes, the Auto- 
coder Processor analyzes the diocs entries to determine 
whether the Overlap and Priority special features 
will be used by the object program. If so, the Proc- 
essor creates a "Channel Scheduler" for each channel 
specified. The Channel Scheduler (s) are to be used 
by the program to schedule overlapping of input/ 
output and processing operations. If needed, the 
Channel Schedulers will be written on the intermediate 
output tape in the form of "one-for-one" symbolic 
statements ( Figure 1 ) . 

Next, the Processor, still using the diocs entries, 
determines which of the iocs routines will be needed 
by the object program. The required routines are 
then also written on the intermediate output tape. 

DTF ENTRIES 

Next, the Processor uses the dtf entries to produce a 
"File Scheduler" for each file used by the program. 
These File Schedulers are later used by the object 
program to arrange for the proper handling of each 
file. 

LINKAGES 

The Processor then examines the programmer's source 
program statements. Each time it encounters an iocs 
macro-instruction, the Processor generates a routine 
and/or a linkage to the appropriate iocs routine (al- 
ready written on the intermediate output tape) and 
writes this routine and/or linkage on the output tape. 

ASSEMBLY OF PROGRAM 

In this manner, the Autocoder Processor creates a 
complete symbolic program. This consists of sections 
written by the programmer and sections made up of 
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Figure 1. Autocoder Assembly of a Program Using the iocs 



iocs routines supplied by ibm Programming Systems. 
The different sections are joined by linkages created 
by the Processor. This symbolic program is converted 
into the object program, i.e., the machine-language 
program, by the Autocoder Processor (Figure 1). 

Channel and File Schedulers 

The Channel Scheduler (s) (one for each channel 
used by programs utilizing the Priority special fea- 
ture) and the File Schedulers (one for each file used 
by the program) are compiled by the Autocoder Proc- 
essor on the basis of the information supplied in the 
diocs and dtf entries. 

CHANNEL SCHEDULER 

When an interrupt occurs, the Channel Scheduler 
senses the cause of the interrupt and provides an exit 



to the appropriate iocs read/write routine to service 
the interrupt. Once the interrupt has been serviced, the 
Channel Scheduler checks to see if any i/o operations 
are pending. Pending i/o operations are executed ac- 
cording to the priority assigned to them by the user 
(see "File Scheduler"). The Channel Scheduler then 
provides a return to the interrupted sequence of in- 
structions. 

FILE SCHEDULER 

Each time a read/write request is encountered, the 
File Scheduler determines which i/o area of the speci- 
fied file will be involved in the operation, and notifies 
the Channel Scheduler of the request. When the chan- 
nel specified is free, the Channel Scheduler notifies the 
File Scheduler that this is the case and the i/o operation 
is executed within the File Scheduler. 



o 



o 



Useofthe 1410 IOCS 



This section consists primarily of a detailed explana- 
tion of the four programming steps required to utilize 
the 1410 iocs, namely, the writing of: 

1. iocs macro-instructions 

2. diocs entries 

3. dtf entries 

4. da entries 
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Figure 2 



The 22 IOCS Macro-Instructions 



This section describes 


in detail the 22 macro-instru 


tions: 




OPEN 


Open File(s) 


CLOSE 


Close File(s) 


CLOSD 


Close Dump Tape 


GET 


Get Logical Record 


PUT 


Put Logical Record 


STACK 


Select Stacker and Feed 


SKIP 


Skip Carriage 


CONSL 


Console Operation 


RTLBL 


Read Tape Label 


WTLBL 


Write Tape Label 


RELSE 


Release Block 


FEORL 


Force End of Reel 


CHKPT 


Write Checkpoint Record 


RDLIN 


Read Label Information 


IOBSP 


i/o Backspace 


IORWD 


i/o Rewind 


IORWU 


i/o Rewind and Unload 


IOWTM 


i/o Write Tape Mark 


PSTAC 


Select Punch Stacker 


RTAPE 


Read Tape 


WTAPE 


Write Tape 


IOSYS 


Clear Channel 



OPEN 

If he does not use the iocs, the programmer must de- 
termine whether the files to be used are properly 
mounted on the tape units specified. He must also 
provide for label processing; i. e., he must provide 
routines to read and check the labels of input files, to 
check the retention codes, and to write new header 
labels for output files. 

By using open macro-instructions, the programmer 
lets the iocs provide the routines necessary to handle 
all of these initializing functions. 

The open macro-instruction is written as indicated 
in Figure 2. 



The operand of the open macro-instruction con- 
sists of the name or names of the file(s) to be acti- 
vated. The names must be those used to describe the 
files in the dtf entries. If more than one file is listed, 
the names must be separated by commas. 

For each file named in the operand of an open 
macro-instruction, the iocs — on the basis of the infor- 
mation contained in the dtf entries —will: 

1. Determine whether a reel of tape is available 
on the tape unit specified. 

2. Rewind the tape (unless otherwise directed by 
the dtf rewind entry). 

3. Process tape labels, if the file has labels. (For 
input files, the iocs will read and check the header 
label. For output files, the iocs will check the re- 
tention code and write a new header label. ) For 
multi-reel files, the services listed under (1), (2) 
and ( 3 ) will be performed automatically for each 
subsequent reel. Checks are made at the end of 
each reel, before records from the next reel are 
used. 

4. Modify the file's channel, drive and priority 
assignments within the iocs if such changes were 
made in the program after assembly. 

(See the section on Tape File Tables, under 
"Additional Information for Programmers. ") 

Tape files using only one input/output area may be 
opened at any time. 

If the programmer uses either the diocs priority 
nonoverlay or priority assemble entries, two-area 
tape files may be opened at any time. 

If the programmer uses the priority nonoverlay, 
origin diocs entry, two-area tape files can be opened 
only before the user's program overlays the Priority 
Assignment Routine. 

If the programmer does not write any diocs priority 
entry, all two-area tape files should be opened by the 
first open macro-instruction. They may, however, be 
closed and reopened later in the program. (Two-area 
tape files initially opened after the first open macro- 
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instruction operate with only the efficiency of a one- 
area file). 

Use of this macro is not mandatory with unit-record 
files. (For these files, the open initializes card or line 
counts. ) 

ibm 1014 Remote Inquiry Unit Files cannot be 
opened by an open macro-instruction which is used 
to open one or more files that are not Remote Inquiry 
Unit Files. 

CLOSE 

The programmer may use the close macro-instruction 
to develop all the coding required to close input and 
output files. 

For each input file named in the operand of a close 
macro-instruction, the iocs will rewind the tape ( unless 
otherwise directed by the dtf rewind entry). 

For each output file named in the operand of a close 
macro-instruction, the iocs will: 

1. Determine whether the output area contains par- 
tially filled blocks. 

2. Write any partially filled blocks of fixed-length 
records remaining in the output area. (Partially 
filled blocks are padded as specified in the dtf 
padding entry. If this entry is omitted, padding is 
done with blanks. ) 

3. Write a tape mark, followed (for standard labels) 
by the trailer label and another tape mark. 

4. Rewind the tape (unless otherwise directed by 
the dtf rewind entry ) . 

Note: When a card output file is closed, a blank 
card will be punched. This causes the last card to be 
selected into the pocket chosen by the programmer. 

The close macro-instruction is written as indicated in 
Figure 3. The operand contains the name or names of 
the file(s) to be closed. The names must be those used 
to describe the files in the dtf entries. If more than one 
file is to be closed, the names must be separated by 
commas. 
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Figure 3 



CLOSD 



The programmer may use the closd macro-instruction 
to develop all the coding required to close the dump 
tape specified in the diocs readerror entry. 

This macro will cause the iocs to: 

1. Write a tape mark (indicating the end of the 
dump file ) . 



2. Rewind the dump tape, if rewind is listed as the 
operand of the macro-instruction. 

3. Rewind and unload the dump tape, if unload is 
listed as the operand of the macro-instruction. 

The closd macro-instruction is written as indicated 
in Figure 4. The operand in the first line specifies that 
the tape is to be rewound. The operand in the second 
line specifies that the tape is to be rewound and un- 
loaded. The absence of an operand in the third line indi- 
cates that the tape is not to be rewound. 
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Figure 4 



GET 



Use of the get macro-instruction makes the next logical 
record available for processing, begins processing end- 
of-reel conditions, or indicates "wrong-length-record" 
conditions by branching to the user's wrong-length- 
record routine. (See dtf wlraddr entry.) Use of this 
macro-instruction also causes a record count and hash 
total to be accumulated and checked against the trailer 
label, if this has been specified by the dtf totals entry. 
The four formats of the get macro are described 
below. 

format 1a 
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Figure 5 

The operand in Figure 5 contains the name of the file 
from which records are to be obtained. The name must 
be that used to describe the file in the dtf header line. 

For unblocked files using one i/o area, this format of 
get will make the next logical record available in the 
area whose label was defined in the file's dtf ioareas 
entry. 

Note: The dtf workarea and indexreg entries may 
not be used to define an unblocked file using one i/o 
area. 

For blocked files using one i/o area and all files using 
two i/o areas, this format will make the next logical 
record available in one of two areas. (If a file uses two 
i/o areas, the diocs features entry for the program 
must include the overlap and priority operands. ) 



o 
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If an index register has been specified in the file's dtf 
indexreg entry, the record is made available in the area 
whose label was specified in the file's dtf ioareas entry 
and the address of the record's high-order position is 
placed in the index register specified. 

If the label of a work area has been specified in the 
file's dtf workarea entry, the next logical record is 
made available in the area which that label defines. 

Note: The dtf indexreg and workarea entries can- 
not both be used to define the same file. 

format 1b 



In Figure 8, the first entry in the operand is the name of 
the file from which records are to be obtained. This 
name must be that used to describe the file in the dtf 
header line. The second entry is the label given to the 
area to which the record is to be moved. The third entry 
(eoflabel) is the label of the user's end-of-file routine. 
In addition to the functions performed by Format 2A, 
this format of the macro-instruction allows the program- 
mer to enter the label of his end-of-file routine at any 
point in the program where he uses Format 2B of the 
get macro. 
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Figure 6 

In Figure 6, the first entry in the operand is the name of 
the file from which records are to be obtained. This 
name must be that used to describe the file in the dtf 
header line. The second entry, eoflabel, is the label of 
the user's end-of-file routine. 

In addition to the functions performed by Format 1A, 
this format of the macro-instruction allows the program- 
mer to enter the label of his end-of-file routine at any 
point in the program where he uses Format IB of the 
get macro-instruction. 

format 2a 
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Figure 7 

In Figure 7, the first entry in the operand is the name 
of the file from which records are to be obtained. This 
name must be that used to describe the file in the dtf 
header line. The second entry is the label given to the 
area to which the record is to be moved. 

For all files except unblocked files using one i/o area, 
this format of get will make the next logical record 
available in the area whose label appears as the second 
entry in the operand. 

Note: The dtf indexreg and workarea entries have 
no effect when this format of the macro is used. 

format 2b 



Line 
3 5 


Label 

6 15 


Operation 
16 20 


21 25 


opI 

30 35 40 45/ 


J u 


AN.V.L.A.Af.L, . 


6 £.7. . 


TMF.l.L.B.t 


la A.R.{.A...f.nJ.LA.* t A.L, \ 


0,2, 









PUT 

Use of the put macro-instruction causes a processed 
record to be written on the output file, or begins process- 
ing of an end-of-file condition. 

Each time the programmer issues a put instruction 
the iocs will: 

1. Place a logical record in the output area. 

2. Write a block of records on the output file when- 
ever enough records have been processed to make 
up an output block. 

3. Cause the program to branch to the end-of-reel 
routine whenever an end-of-reel condition is en- 
countered in the output file. 

4. Accumulate record-count and hash-total informa- 
tion for insertion in the trailer label, if this has 
been specified by the dtf totals entry. 

The three formats of the put macro-instruction are 
described below. 

FORMAT A 
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Figure 8 



Figure 9 

The first entry in the operand in Figure 9 is the name of 
the work area as defined by the da statement. The name 
of the file entered in the operand must be that used to 
describe the file in the dtf header line. 

The macro-instruction causes the logical record in the 
work area to be included in the specified output file. 

Note: Word marks in the work area are moved with 
the logical record to the output area of the specified file. 

FORMAT B 

In Figure 10, the first entry in the operand is the name of 
the file from which the current logical record is taken. 
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Figure 10 

The name must be that used to describe the file in the 
dtf header line. 

The last entry in the operand is the name of the file to 
which the logical record is to be moved. The name must 
be that used to describe the file in the dtf header line. 

The function of this format of the macro-instruction 
depends on record type and the number of input/out- 
put areas, as follows : 

1. For blocked files using only one input/output area 
and for all files using two input/output areas:* 

a. If indexing is used for File 1, the put macro- 
instruction will move the current logical record 
from the input area to the specified output file. 

b. If indexing is not used for File I, the put macro- 
instruction will move the current logical record 
from the work area specified by the dtf work- 
area entry to the specified output file. 

2. For all unblocked files using only one input/output 
area, the put macro-instruction will move the cur- 
rent logical record from the input area to the speci- 
fied output file. 

FORMAT C 
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Figure 11 

Format C of the put macro-instruction, shown in Figure 
11, is used only if the programmer wishes to place 
records into the output area by actual move commands. 
In this case, the programmer must use the put filename 
macro-instruction to enable the iocs to account for the 
records so moved. The operand of this macro-instruc- 
tion is the name of the output file into which records are 
moved. 

The conditions under which the put filename macro- 
instruction may be used for the different record formats 
are shown in Figure 12. 

STACK 

This macro-instruction corresponds to the ssf (Select 
Stacker and Feed ) mnemonic operation code. ( See IBM 
1410 Principles of Operation, Form A22-0526.) The 
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Figure 12. Conditions for the Use of the put filename Macro- 
Instruction 



macro-instruction is used to select cards into specified 
pockets when the file uses the dtf cardpoc entry. 

This macro-instruction will generate the coding re- 
quired to: 

1. Stack the card that was read on the last card-read 
cycle into the pocket specified by the first operand 
of the macro-instruction. 

2. Check for error conditions. 

The first operand of this macro-instruction is: 

if the card is to be selected into the nr pocket. 

1 if the card is to be selected into pocket 1. 

2 if the card is to be selected into pocket 2. 
The second operand of this macro-instruction is: 

x or chanx where x is the channel to which the 
1402 Card Read Punch is attached. 

Note: If the 1402 Card Read Punch is attached to 
channel 1 the second operand may be omitted. 

The example on line 1 of Figure 13 indicates that the 
card just read by the 1402 Card Read Punch attached to 
channel 1 is to be selected into pocket 1. 
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Figure 13 

The examples on lines 3 and 5 of Figure 13 indicate 
that the card just read by the 1402 attached to channel 
2 is to be selected into pocket 1. 
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SKIP 

This macro-instruction corresponds to the cc (Control 
Carriage) mnemonic operation code. (See IBM 1410 
Principles of Operation, Form A22-0526. ) 

This macro-instruction will generate the coding re- 
quired to: 

1. Skip the tape-controlled carriage of the ibm 1403 
Printer to the tape channel specified by the first 
operand of the macro-instruction. 

2. Check for error conditions. 

The first operand of this macro-instruction is the ap- 
propriate d-character, as indicated in Figure 15. 
The second operand of the macro-instruction is : 
x or chanx where x is the channel to which the 
printer is attached. 
Note: if the printer is attached to channel 1, the sec- 
ond operand may be omitted. 

The example on line 1 of Figure 14 indicates that the 
carriage of the 1403 Printer attached to channel 1 is to 
skip to ( carriage control tape ) channel 1 after printing. 

The examples on lines 3 and 5 indicate that the car- 
riage of the 1403 Printer attached to channel 2 is to skip 
to ( carriage control tape ) channel 1 after printing. 
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Figure 14 
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Figure 15. d-Character for Control Carriage Macro 

CONSL 

This macro-instruction will generate the coding re- 
quired to : 

1. Perform the console operation specified by the 
operands of the macro-instruction. 



2. Check not ready, busy, data check, and condi- 
tion indicators. 

Note: A consl macro-instruction with an rcp 
operand is executed only after the console Inquiry Re- 
quest key has been pressed. If this key has not been 
pressed before this consl macro-instruction is encoun- 
tered, the iocs enters a waiting loop until the console 
Inquiry Request key is pressed. 

The operands of the consl macro-instruction are: 

1. A letter code indicating the manner in which the 
console operation is to be performed. 

2. The label of the area into or from which informa- 
tion is to be read or written. 

The first operand of this macro-instruction is : 
wcp ( Write Console Printer ) or 
rcp ( Read Console Printer ) , 

if the operation does not use the Overlap special 
feature and takes place in the move mode. 
wcpo (Write Console Printer, Overlap) or 
rcpo (Read Console Printer, Overlap), 

if the operation uses the Overlap special feature 
and takes place in the move mode. 
wcpw (Write Console Printer, Word Marks) or 
rcpw ( Read Console Printer, Word Marks ) , 
if the operation takes place in the load mode and 
does not use the Overlap special feature. 
wcpwo (Write Console Printer, Word Marks, 

Overlap ) or 
rcpwo (Read Console Printer, Word Marks, 
Overlap ) , 

if the operation uses the Overlap special feature 
and takes place in the load mode. 
The example in Figure 16 indicates that the informa- 
tion contained in the area labeled message is to be writ- 
ten in the move mode on the console printer without use 
of the Overlap special feature. 
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Figure 16 

The example in Figure 17 indicates that information 
typed out on the console printer is to be read in the 
move mode and, with use of the Overlap special fea- 
ture, into the area labeled datearea. 
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Figure 17 

Note: Message areas must have a group mark with 
word mark immediately to the right of the low-order 
position. 
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RTLBL 

The programmer may use the rtlbl macro-instruction 
to generate all the coding necessary to read nonstand- 
ard tape labels. 

This macro-instruction will generate the coding re- 
quired to: 

1. Read the nonstandard tape label in the area speci- 
fied by the third operand of the macro. 

2. Check for busy, not ready and data check con- 
ditions. 

The operands of the rtlbl macro-instruction are: 

1. The code indicating the manner in which the tape 
is to be read. 

2. A two-digit number indicating the channel and 
drive of the tape on which a nonstandard label is 
to be read. 

3. The label of the area in storage into which the 
label is to be read. 

The first operand is : 

rt if the label is to be read in even parity and 
the move mode, and the use of the Overlap 
special feature has not been specified in the 
operand of the diocs features entry. 
The following code letters must be added to the rt 
code, if the conditions described below apply. 
B if the label is to be read in odd parity. 
W if the label is to be read in the load mode ( i.e., 

with word marks ) . 
O if use of the Overlap special feature has been 
specified in the operand of the diocs features 
entry. 
Note: These code letters are added to the rt code in 
the order in which they are discussed above. 
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Figure 18 

The example in Figure 18 indicates that the label in- 
formation is to be read in even parity and in the load 
mode into the area labeled lablarea from tape unit 3 
on channel 1, without using the Overlap special 
feature. 

WTLBL 

The programmer may use the wtlbl macro-instruction 
to generate all the coding necessary to write nonstand- 
ard tape labels. 

This macro-instruction will generate the coding re- 
quired to: 

1. Write the nonstandard tape label in the area speci- 
fied by the third operand of the macro. 

2. Check for busy, not ready and data check con- 
ditions. 



The operands of the wtlbl macro-instruction are: 

1. The code indicating the manner in which the tape 
is to be written. 

2. A two-digit number indicating the channel and 
drive of the tape on which a nonstandard label is 
to be written. 

3. The label of the area in storage from which the 
label is to be written. 

The first operand is : 

wt if the label is to be written in even parity and 

the move mode, and the use of the Overlap 

special feature has not been specified in the 

operand of the diocs features entry. 

The following code letters must be added to the wt 

code, if the conditions described below apply. 

B if the label is to be written in odd parity. 
W if the label is to be written in the load mode 

(i.e., with word marks ) . 
O if use of the Overlap special feature has been 
specified in the operand of the diocs features 
entry. 
Note: These code letters are added to the wt code in 
the order in which they are discussed above. 
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Figure 19 

The example in Figure 19 indicates that the informa- 
tion contained in the area labeled trailarea is to be 
written in odd parity and the move mode on tape unit 
7 of channel 2, using the Overlap special feature. 

Note: The rtlbl and wtlbl macro-instructions are 
intended primarily for the convenience of programmers 
using Exits 2, 5, 6 and 7 to process nonstandard tape 
labels. 

RELSE 

The programmer may use the relse macro-instruction 
to develop all the coding required to force the release of 
a partially processed input block or a partially filled 
output block. Thus, this macro-instruction will cause 
the next get or put instruction to refer to the next block 
of the file. 

For input files, this macro will cause the first logical 
record of the next block to be obtained when the next 
get macro is encountered. 

For output files, this macro-instruction will cause the 
block being built in the output area to be written onto 
the output file. Blocks consisting of Form 2 Records will 
be padded, if necessary, as specified in the dtf padding 
entry. (If this entry was omitted for this file, partially 
filled blocks will be padded with blanks. ) For padded 
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blocks, the output area must contain a record mark to 
insure proper padding. See sections on da Entries for 
iocs, Output, "Blocked, Fixed-Length Records," and 
"Form 2 Record Format/' 

Note: Record counts and hash totals cannot be taken 
for input files affected by the relse macro, because 
records are skipped during processing. These counts and 
totals may be used, however, for output files affected 
by the relse macro-instruction. Block counts are taken 
automatically for both input and output files affected 
by relse macro-instructions. 
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Figure 20 

The operand of this macro-instruction (Figure 20) 
is the name of the file to be released. The name must be 
that used to define the file in the dtf header line. 

FEORL 

The programmer may use this macro-instruction to de- 
velop all the coding required to force the program to 
branch to an end-of-reel routine. ( The end-of -reel-rou- 
tine options available to the programmer are listed in 
the description of the dtf typelabel entry. ) 

For output files, this macro-instruction will: 

1. Pad partially filled, fixed-length, blocked records 
(either with the character specified in the dtf 
padding entry or with blanks if the dtf padding 
entry was omitted ) . 

2. Write out all records contained in the output area. 

3. Cause the program to branch to an end-of-reel 
routine, with options as specified in the dtf entries. 

For input files, this macro-instruction will: 

1. Cause the program to branch to an end-of-reel 
routine, with options as specified in the dtf entries. 
( No check is made to determine whether an end- 
of -file conditions exists, and the trailer label is not 
processed. ) 
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Figure 21 

The operand in Figure 21 is the name of the file for 
which an end-of-reel condition is to be assumed. The 
name is that used to define the file in the dtf header 
line. Only one file may appear in the operand. 



CHKPT 

The chkpt macro-instruction ( see Figure 22 ) develops 
all the coding required to cause the program to branch 
to the Checkpoint Routine. The Checkpoint Routine 
causes a checkpoint to be written on the tape unit speci- 
fied by the diocs checkpoint entry. A checkpoint con- 
sists of two records. The first record (i.e., the control 
record ) contains : an identifier that notifies the iocs that 
a checkpoint is to follow, the number of the checkpoint, 
and the four address constants required to restart the 
program. The second record includes the entire contents 
of core storage. This information allows partially run 
programs to be restarted at the point in the program 
where the checkpoint was taken. 
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Figure 22 

The chkpt macro-instruction can be entered from the 
console printer at any time, if: (a) the diocs inquiry 
entry has been omitted, and (b) the overlap and 
priority operands of the diocs features entry have 
been specified. The chkpt macro-instruction is entered 
as follows: (a) the operator presses the Inquiry Re- 
quest key, ( b ) enters chkpt, and ( c ) presses the Inquiry 
Release key. 

If a checkpoint record is to be taken, the last 4,400 
positions of core storage cannot contain any information 
provided by dtf or diocs entries. 

The operand field of the chkpt macro-instruction is 
left blank. 



RESTARTING FROM A CHECKPOINT 

To restart a program from a checkpoint, a control card 
that conforms to the format shown below must be placed 
in the card reader immediately following the restart 
program deck. 

COLUMN CONTENTS 

1-7 **CHKPT 



8-10 

11-12 
13-14 

15 
16 
17 



Three-digit checkpoint number of the checkpoint 
from which the program is to be restarted. 



R% if the checkpoint from which the jprogram 
is to be restarted was taken on channel 1; RX 
if the relevant checkpoint was taken on channel 2. 

Number of the tape drive on which the checkpoint 
was written. 

U for even parity. (Checkpoints are always written 
in even parity. ) 

% if the user's program utilizes channel 1 and does 
not utilize the Overlap and Priority special fea- 
ture. @ if the user's program utilizes channel 1 
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COLUMN CONTENTS 

and does utilize the Overlap and Priority special 
feature. 
n if the user's program utilizes channel 2 and 
does not utilize the Overlap and Priority special 
feature. 

* if the user's program utilizes channel 2 and does 
utilize the Overlap and Priority special feature. 

H3 if the user's program utilizes channel 1 and chan- 
nel 2 and does not utilize the Overlap and Priority 
special feature. 

* if the user's program utilizes channel 1 and chan- 
nel 2 and does utilize the Overlap and Priority 
special feature. 

The restart program reads this control card and 
searches the checkpoint file for the relevant control 
record. When the relevant control record has been 
located, the restart program reads into core storage 
the information (i.e., the storage dump) that is written 
on the checkpoint file following the control record. The 
restart program then uses the seven address constants 
contained in the relevant control record to obtain the 
information necessary to restart the program, and pro- 
ceeds to execute the restart. 

MODIFICATION OF THE RESTART PROGRAM 

The restart program is provided by ibm in the form of a 
symbolic card deck. It occupies the first 3,700 positions 
of core storage. Under certain conditions the program- 
mer must modify this program. These conditions and 
the necessary modifications are as follows : 
Condition: None of the tape files referenced by the 
program that is to be restarted use standard labels, 
but one or more use nonstandard labels. 

Modification: The programmer must write a routine 
capable of reading the nonstandard labels, and include 
that routine in the restart program. The programmer 
must also place the address of his routine in the appro- 
priate portion of the branch instruction at rsnonstd+1, 
and change the nopwm at rsnonstd to nop. 
Condition: One or more of the tape files referenced by 
the program that is to be restarted use two or more 
header labels on each reel of tape. 

Modification: The programmer must write a routine 
that is capable of reading the additional header labels 
and include that routine in the restart program. This 
routine should read the additional labels into the area 
labeled rsdumy within the restart program. After each 
additional label is read, the user's routine should branch 
to rseror. rseror is the label of the tape error routine 
included in the restart program. The programmer must 
also place a word mark at pglin 0132, and insert the 
address of his routine in the appropriate portion of the 
branch instruction found at pglin 0132. 

RDUN 

The programmer may use the rdlin macro-instruction 
to: 



1. Modify the DTF-specified information against 
which standard input header labels will be 
compared. 

2. Specify changes in the DTF-specified standard out- 
put header labels. 

The rdlin macro-instruction should be given before the 
affected file is opened. 
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Figure 23 

The operand in Figure 23 consists of the name or 
names of the file(s) for which label handling is to 
be modified. The names must be those used to define 
the files in the dtf header lines. If more than one file is 
named, their names must be separated by commas. 

For each file named in the operand of the rdlin 
macro-instruction, the iocs will cause a card to be read 
into storage. The information contained in columns 
21-50 of this card will become the information against 
which standard header labels are to be checked, or from 
which standard output header labels are to be written. 
This label-checking information replaces that originally 
supplied by the dtf entries for the file. Columns 16-20 
must contain the characters rdlin. 

For input files, columns 21-45 of this card should 
contain the information which is to be used to check 
the file's serial number, reel sequence number, file 
name, and creation date contained in the header label. 
That is, the columns should contain: 



INFORMATION 


COLUMNS 


RDLIN 


16-20 


File Serial Number 


21-25 


Reel Sequence Number 


26-30 


File Name 


31-40 


Creation Date 


41-45 



The rdlin macro-instruction thus enables the pro- 
grammer to modify the information against which 
( standard input ) header labels will be compared during 
the running of the program. 

For output files, columns 21-50 of the card should 
contain the information which is to be inserted into the 
standard output header labels to be written during the 
running of the program. This information should be of 
the same format as listed under input files, above. In 
addition, columns 46-50 should contain the retention 
cycle. This field will be checked when output header 
labels are read to determine whether or not the tape 
may be written upon. 

The rdlin macro-instruction enables programmers to 
modify the information written on standard output 
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header labels during the running of the program. All 
rdlin cards affecting files opened by the first open 
macro-instruction encountered in an object program 
must be placed immediately following the first Execute 
card ( identified by the character E in column 1 ) in the 
object program deck, if; (a) the diocs priority entry 
has been omitted, and (b) the overlap and priority 
operands of the diocs features entry have been speci- 
fied. In all other cases, the placement of rdlin cards is 
not critical. 

If more than one file is named in the operand of a 
rdlin macro-instruction, the cards must be entered into 
the card reader in the order of the files to which they 
refer. 

If a rdlin macro-instruction is used, the programmer 
must enter the word rdlin as one of the operands of the 
diocs labeldef "entry. 

IOBSP 

This macro-instruction corresponds to the bsp (Back- 
space Tape) mnemonic operation code. (For this and 
the following macro-instructions, see IBM 1410 Princi- 
ples of Operation, Form A22-0526. ) 

This macro-instruction will generate the coding re- 
quired to : 

1. Backspace the tape unit (specified by the oper- 
and of this macro-instruction) over one tape 
record. 

2. Check for error conditions. 

Note: A tape mark is considered a tape record. 
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Figure 24 

The operand in Figure 24 indicates that tape unit 5 
of channel 1 is to be backspaced over one tape record. 

IORWD 

This macro-instruction corresponds to the rwd ( Rewind 
Tape) mnemonic operation code. This macro-instruc- 
tion will generate the coding required to: 

1. Rewind the tape unit (specified by the operand 
of this macro-instruction ) . 

2. Check for error conditions. 



IORWU 

This macro-instruction corresponds to the rwu (Re- 
wind and Unload) mnemonic operation code. This 
macro-instruction will generate the coding required to: 

1. Rewind the tape unit (specified by the operand 
of this macro-instruction ) . 

2. Unload the reel of tape. 

3. Check for error conditions. 
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Figure 26 

The operand in Figure 26 indicates that tape unit 8 
of channel 1 is to be rewound and unloaded. 

IOWTM 

This macro-instruction corresponds to the wtm ( Write 
Tape Mark) mnemonic operation code. This macro- 
instruction will generate the coding required to: 

1. Write a tape mark (a single-character record in 
even parity ) on the tape specified by the operand 
of this macro-instruction. 

2. Check for error conditions. 
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Figure 27 

The operand in Figure 27 indicates that a tape mark 
is to be written on the tape on tape unit 1, channel 2. 

PSTAC 

This macro-instruction enables the programmer to se- 
lect punched cards into pockets other than those speci- 
fied by the dtf cardpoc entries. 

This macro-instruction will develop the coding re- 
quired to select punched cards into the pocket ( 0, 4 or 
8) specified by the operand of the pstac macro- 
instruction instead of the pocket specified by the dtf 
cardpoc entry. Thus, in the coding sequence: 
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Figure 25 

The operand in Figure 25 indicates that tape unit 7 
of channel 2 is to be rewound. 
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(3) 


PUT 


(4) 


PUT 


(II) 


PSTAC 


(5) 


PUT 


(6) 


PUT 



cards punched as the result of put s ( 1 ) and ( 2 ) will 
be selected into the pockets specified by the dtf 
cardpoc entries of the respective files. Cards punched 
as the result of puts (3) and (4) will be selected into 
the pocket specified by the first pstac macro-instruction 
(I). Cards punched by puts (5) and (6) will be se- 
lected into the pocket specified by the second pstac 
macro-instruction ( II ) , etc. 

A punch output file using the pstac macro-instruction 
must have a dtf cardpoc entry. 

Punched cards (except error rejects) are always 
selected into the pocket indicated by the command 
that punched them. 

The first operand of the pstac macro-instruction 
identifies the pocket into which cards are to be selected 
( see Figure 28 ) . 

The second operand of this macro-instruction is: 
x or chanx where x is the channel to which the 

punch is attached, or 
pp where pp is the operand of this punch file's 
dtf prefix entry, if that entry was used in 
defining the file. 

Note: If the 1402 Card Read Punch is attached to 
channel 1, this operand may be omitted unless a dtf 
prefix entry was used in defining the file involved in 
this operation. 
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Figure 28 

The example on line 1 of Figure 28 indicates that 
all cards following this macro-instruction are to be 
selected into pocket 8 of the 1402 Card Read Punch 
until another pstac macro is encountered. The ex- 
amples on lines 3 and 5 of Figure 28 indicate that all 
cards are to be selected into pocket 8 of the 1402 at- 
tached to channel 2. The example on line 7 indicates 
that all cards are to be selected into pocket 8 of the 
1402 attached to the channel indicated by the pp oper- 
and of this file's dtf filetype entry. 



RTAPE 

This macro-instruction enables the programmer to read 
a tape record from any tape unit ( independently of the 
get/put logic of the iocs ) . Input files for which there is 
a dtf scheduler no entry can be read only with this 
macro-instruction. Also, it is not necessary (though it 
is permissible ) to write a set of dtf entries for files ad- 
dressed by the rtape macro-instruction. 

This macro-instruction must never be used for two- 
area tape files. 

This macro-instruction will develop the coding re- 
quired to: 

1. Read a record from the tape unit specified in the 
operand of this macro-instruction. 

2. Check for all error conditions except the wrong- 
length-record indication. 

In addition, if the programmer wishes, this macro- 
instruction can direct the iocs to indicate the availabil- 
ity to input records by means of a program switch. ( See 
fourth operand. ) 

By using another operand, the programmer can also 
direct the iocs to store the contents of the B-, E-, or F- 
address register upon the completion of the read opera- 
tion. (B Register for non-overlapped operations on 
either channel, E Register for overlapped operations on 
channel 1, F Register for overlapped operations on 
channel 2. ) The object program can then use this infor- 
mation to determine the length of individual records 
from a file of variable-length records. (See sixth 
operand. ) 
The first operand of the rtape macro-instruction is: 
rt if the record is to be read in even parity, in the 
move mode, and use of the Overlap special fea- 
ture has not been specified in the operand of the 
diocs features entry. The following code letters 
must be added to the rt code, if the conditions 
described below apply. 
B if the record is to be read in odd parity. 
G if the record read is to be terminated only by 
the inter-record gap. 

if the record is to be read in the load mode, 
if use of the Overlap special feature has been 
specified in the operand of the diocs features 
entry. 

These code letters are added to the rt code in 
the order in which they are discussed above. 

The second operand is a two-digit number of the 
form cu, where 

c indicates the channel 
u indicates the tape unit. 
The third operand is the label of the input area into 
which the record is to be read. 

The fourth operand, which is optional, is the label 
of a core-storage position that the iocs can use as a 
switch to indicate the availability of input records. 
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(When the rtape is issued, the iocs sets a word mark at 
this location; when the read operation has been success- 
fully completed, the iocs clears the word mark. ) This 
operand is used only for overlapped read operations. An 
rto operation that has this operand is both scheduled 
and overlapped by the iocs. 

The fifth operand is the label of the users end-of-file 
routine for the input tape addressed by the rtape 
macro-instruction. The iocs transfers control to this 
routine when an end-of-file condition results from the 
read operation. This operand must be included if there 
are no dtf entries for the file. If there is sl set of dtf 
entries for the file, then the dtf eofaddr entry supplies 
the label of the end-of-file routine. However, if the fifth 
operand is included for this macro-instruction in addi- 
tion to a dtf eofaddr entry, the iocs branches to the 
end-of-file routine specified by the operand, and no re- 
lation between the file and the macro-instruction is es- 
tablished. 

If the fourth and fifth operands are both specified, the 
user's end-of-file routine must store the contents of the 
B-Register, note that an end-of-file condition exists ( e.g., 
set a word mark switch), and branch to the stored con- 
tents of the B-Register — without executing any i/o 
macro-instructions, entering priority alert, or disturb- 
ing the High-Low-Equal or Zero Balance indicators. 
The reason for this procedure is that the user's end-of- 
file routine has been entered as a result of an interrupt 
caused by completion of the i/o operation which 
caused the end-of-file condition. 

The sixth operand, which is optional, is the label of a 
five-position area into which the iocs can store the con- 
tents of the B-, E-, or F-address register upon completion 
of the read operation. 

The rtape macro-instruction does not generate the 
coding required to increment block counts, record 
counts, or hash totals. However, the programmer can 
himself increment these counts at the following points: 

1. If the affected file has been defined (by means of 
dtf entries ) the block count can be incremented 
at iocscutbc where u is the tape unit the file is 
using and c is the channel to which that unit is 
attached. If the program is restarted from a check- 
point, the relevant tapes cannot be properly re- 
positioned unless the affected block counts are up 
to date. 

2. If the first operand (i.e., record) of both the diocs 
counts entry and the dtf totals entry has been 
specified, the record count of the affected file can 
be incremented at iocscutrc where c and u have 
the same values noted above. 

3. If the second operand of the diocs counts entry 
(i.e., hash) and the second operand of the dtf 
totals entry (i.e., an appropriate integer) have 



been specified, the hash total of the affected file 

can be incremented at iocscutht where c and u 

have the same values noted above. 

The fields at iocscutbc, iocscutrc and iocscutht are 

set to blanks by the iocs each time an end-of-reel 

condition occurs on the affected file. 

The contents of the fields at iocscutbc, iocscutrc and 
iocscutht are included by the iocs in the trailer labels 
of reels belonging to the affected file if standard labels 
have been specified for that file. 
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Figure 29 

The operand field in Figure 29 specifies that a record 
is to be read from tape unit 3, which is on channel 2, into 
areaI. The record is to be read in odd parity, in the 
move mode, and the read operation is to be overlapped 
with processing. The entry also directs the iocs to set a 
word mark at insw when this macro-instruction is issued 
by the program. When the read operation has been suc- 
cessfully completed, the iocs will clear the word mark 
at insw and store the contents of the F-address regis- 
ter (channel 2 operation) into storadreg. 

Note: Assume that the file on tape 23 has been de- 
fined by a set of dtf entries. Because it is an input file, 
the dtf eofaddr entry was required. Therefore, the fifth 
operand of this macro-instruction need not be included, 
but must be indicated by a comma. (The comma en- 
ables the Autocoder Processor to recognize storadreg 
as the sixth operand, rather than the fifth. ) 

WTAPE 

This marco-instruction enables the programmer to write 
a record on any tape unit ( independently of the get/put 
logic of the iocs). Output files for which there is a dtf 
scheduler no entry can be written only with this macro- 
instruction. Also, it is not necessary (though it is per- 
missible) to write a set of dtf entries for files addressed 
by the wtape macro-instruction. 

This macro-instruction will develop the coding re- 
quired to: 

1. Write a record onto the tape unit specified in the 
operand of this macro-instruction. 

2. Check for all error conditions. 

In addition, if the programmer wishes, this macro- 
instruction can direct the iocs to indicate the avail- 
ability of output areas by means of a program switch. 
( See fourth operand. ) 
The first operand of the wtape macro-instruction is: 
wt if the record is to be written in even parity, 
in the move mode, and use of the Overlap 
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special feature has not been specified in the 
operand of the diocs features entry. 
The following code letters must be added to the wt 
code, if the conditions described below apply. 

B if the record is to be written in odd parity. 

E if the write operation is not to be terminated 

until the end of core storage has been reached. 

W if the record is to be written in the Load mode. 

O if use of the Overlap special feature has been 

specified in the operand of the diocs features 

entry. 

Note: These code letters are added to the wt code in 
the order in which they are discussed above. 

The second operand is a two-digit number of the 
f oral cu, where 

c indicates the channel 
u indicates the tape unit. 

The third operand is the label of the output area from 
which the record is to be written. 

The fourth operand, which is optional, is the label of 
a core-storage position that the iocs can use as a switch 
to indicate the availability of the output area. (When 
the wtape is issued, the iocs sets a word mark at this lo- 
cation; when the write operation has been successfully 
completed, the iocs clears the word mark. ) This oper- 
and is used only for overlapped write operations. A wto 
operation that has this operand is both scheduled and 
overlapped by the iocs. 

The fifth operand is the label of the user's end-of-reel 
routine for the output tape addressed by the wtape 
macro-instruction. The iocs transfers control to this rou- 
tine when an end-of-reel condition results from the write 
operation. This operand must be included if there are 
no dtf entries for the output file. ( If there is a set of dtf 
entries for the file, and this operand is not used, the iocs 
automatically handles the end-of-reel condition in ac- 
cordance with the specifications of the dtf entries.) 

If the fourth and fifth operands are both specified, the 
user's end-of-file routine must store the contents of the 
B-Register, note that an end-of-file condition exists, and 
branch to the stored contents of the B-Register — with- 
out executing any i/o macro-instructions, entering pri- 
ority alert, or disturbing the Hi-Low-Equal or Zero 
Balance indicators. The reason for this procedure is that 
the user's end-of-file routine has been entered as a result 
of an interrupt caused by completion of the i/o opera- 
tion that caused the end-of-file condition. 

The wtape macro-instruction does not generate the 
coding required to increment block counts, record 
counts, or hash totals. However, the programmer can 
himself increment these counts at the following points: 

1. If the affected file has been defined (by means of 
dtf entries ) the block count can be incremented 
at iocscutbc where c is the tape unit the file is 



using and u is the channel to which the unit is at- 
tached. If the program is restarted from a check- 
point, the relevant tapes cannot be repositioned 
properly unless the affected block counts are up to 
date. 

2. If the first operand ( i.e., record ) of both the Diocs 
counts entry and the dtf totals entry has been 
specified, the record count of the affected file can 
be incremented at iocscutrc where c and u have 
the values noted above. 

3. If the second operand of the diocs counts entry 
(i.e., hash) and the second operand of the dtf 
totals entry (i.e., the appropriate integer) have 
been specified, the hash total of the affected file 
can be incremented at iocscutht where c and u 
have the same values noted above. 

The fields at iocscutbc, iocscutrc, and iocscutht are 
set to blanks by the iocs each time an end-of-reel con- 
dition occurs on the affected file. 

The contents of the fields at iocscutbc, iocscutrc, 
and iocscutht are included by the iocs in the trailer 
labels of reels belonging to the affected file if standard 
labels have been specified for that file. 

The operand field in Figure 30 specifies that a record 
is to be written from area2 onto tape unit 3, which is on 
channel 2. The record is to be written in odd parity, 
in the move mode, and the write operation is to be over- 
lapped with processing. The entry also directs the iocs 
to set a word mark at outsw when this macro-instruc- 
tion is issued by the program, and to clear that word 
mark when the write operation has been successfully 
completed. If an end-of-reel condition occurs, the iocs 
will transfer control to the routine labeled eorrtn. 
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Figure 30 

IOSYS 

This macro-instruction allows the programmer to issue 
i/o instructions ( other than iocs i/o macro-instructions ) 
to i/o devices on either channel, during execution of 
any object program utilizing the iocs with the Overlap 
and Priority special features. This macro-instruction 
has two formats. 

FORMAT A 

The operand on the first line of Figure 31 specifies that 
all channels defined in the diocs chanx entry, or entries, 
are to be cleared^The operand on the second line speci- 
fies that channel 1 is to be cleared. The operand on the 
third line specifies that channel 2 is to be cleared. The 
operand on the fourth line specifies that both channel 
1 and channel 2 are to be cleared. 
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Figure 31 

This format of the macro-instruction will establish 
an uninterruptible waiting loop in the Channel Sched- 
ule^ s) specified. Then, it will terminate the waiting 
loop when the currently overlapping i/o operation in 
process on the channel(s) specified (if any) is com- 
pleted and errors resulting from the i/o operation (if 
any) are corrected. The next sequential instruction in 
the user s program is then executed, but the iocs does 
not initiate any i/o operations that are pending on the 
channel(s). 

FORMAT B 
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Figure 32 

This format of the macro-instruction will return con- 
trol of the program to the iocs and allow the iocs to 
initate any i/o operations that are pending on the chan- 
nel or channels cleared by iosys pause. This form is 
used to negate the effect of iosys pause (Figure 32). 



The DIOCS Entries 

Before the programmer can use the Input/Output Con- 
trol System, he must supply the Autocoder Processor 
with the information needed to determine which of the 
iocs routines are required by the object program. De- 
pending on installation features and the program, this 
information consists of two or more card entries listed 
individually on the ibm 1401/1410 Autocoder coding 
sheet. These entries define the Input/Output Control 
System required by the particular object program, and 
are known collectively as the diocs ( Define Input/Out- 
put Control System) entries. Each entry is described in 
detail. 

Note: The diocs entries merely specify the sections of 
the Input/Output Control System which are to be in- 
cluded in the object program. These sections will be in- 
cluded, but they need not necessarily be used. Thus, 
although the programmer may have specified Exit 5 
in the diocs exits entry, he is not obliged to use this exit. 



General Format 

The first diocs entry consists of the code diocs in the 
operation field. Each subsequent diocs entry has a 
blank operation field and must have one of the labels 
listed below. All diocs entry cards may contain com- 
ments which must be separated from the diocs entry 
by at least two adjacent blanks. The diocs entries fol- 
lowing the header line may be listed in any order. The 
diocs and the chanx entries are mandatory. The remain- 
ing entries are not always required. 

List of DIOCS Entries 

This section describes the purpose of each of the follow- 
ing entries : 



diocs header line 

DIOCSORG 

FEATURES 

CHANX 

LABELDEF 

ALTDRIVE 

EXITS 

COUNTS 



RWDOPTION 

READERROR 

PRIORTY 

CHECKPOINT 

CHANCHANGE 

INQUIRY 

URREQUEST 



The DIOCS Header Line 

The first diocs entry ( Figure 33 ) is mandatory and con- 
sists of the entry diocs in the operation field. It is known 
as the "diocs header line." This card must be the first 
card ( except for special control cards such as autocoder 
run, pst, job, comments and ctl) to enter the system 
during Autocoder assembly. 
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Figure 33 

DIOCSORG 

If this entry is not made, the Autocoder Processor will 
begin assembly of iocs information at core location 500. 
If the programmer wants iocs assembly to begin at 
another location, the actual address of this locati on must 
be listed as the operand of the diocsorg entry. 




Figure 34 

The entry in Figure 34 will cause the iocs information 
to be assembled, beginning in location 1000. 
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Depending on the mode of operation and the use of 
certain special features, assembly of iocs routines must 
begin above certain core-storage locations: 

1. If the Overlap and Priority special features are 
used, iocs assembly must begin above location 115. 

2. If standard labels are used, iocs assembly must 
begin above location 119. 

3. If the standard Autocoder Loader is used, iocs 
assembly must begin above location 397. 

FEATURES 

This entry is not needed if the object program does not 
utilize channel 2 or the Overlap and Priority special 
features. The operands of the features entry are: 
overlap if the program uses the Overlap special 
feature. ( The present iocs does not provide over- 
lapping without the Priority special feature. ) 
priority if the program uses the Priority special 
feature. 
The operands must be separated by commas and may 
be entered in any order. 
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Figure 35 

The entry in Figure 35 indicates that the object pro- 
gram uses the channel 2 and the Overlap and Priority 
special features. 

CHANx 

The x in chanx indicates the channel to which the in- 
put/output devices ( specified in the operand field ) are 
attached. Therefore, if all devices that are to be con- 
trolled by the iocs are on one channel, one chanx entry 
is included in the source deck. If the input/output de- 
vices are on two channels, then two chanx entries are 
included in the source deck: one entry specifying all 
the devices attached to channel 1 and the other speci- 
fying all the devices attached to channel 2. 

chanI or chan2 is written in the label field and one 
or more of the following devices can be specified in the 
operand field: 



OPERAND 


DEVICE 


TAPE 


Magnetic Tape Unit 


READER 


Card Reader 


PUNCH 


Card Punch 


PRINTER 


132-character Printer ( Model 2 ) 


1405 


1405 Disk Storage 


1301 


1301 Disk Storage 
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Figure 36 



The first entry in Figure 36 indicates to the iocs that 
the object program requires coding for the following 
channel 1 operations: tape, card (both input and out- 
put), and printer. The second entry indicates that the 
program also requires coding for tape and 1301 Disk 
operations on channel 2. 



LABELDEF 

This entry is not needed if the object program does not 
use tape files or if the tape files used by the object pro- 
gram have no labels. The operands of the labeldef 
entry are: 

standard if the program uses only ibm standard 
tape labels. 

nonstandard if the program uses nonstandard tape 
labels and none of the files use standard labels. 

mixed if some files have standard labels and some 
files have either nonstandard or no labels, or 
both. 

check if there are one or more files with standard 
labels which are to be completely checked. This 
operand may not be used if the ident operand is 
used. 

ident if there are one or more files with standard 
labels for which only the identification field of 
the header labels is to be checked, and if none 
of the header labels are to be completely check- 
ed. This operand may not be used if the check 
operand is used. The diocs check entry develops 
all the coding necessary for the complete check- 
ing of standard labels. Therefore, should the 
programmer desire to check only the identifica- 
tion fields of some files, he can do so — even 
though he specified the diocs check entry. The 
check entry will provide the necessary coding as 
part of the coding required for the complete 
checking of standard labels. 

tm if one or more tape files have a tape mark be- 
tween the header label and the first block of 
records. A tape mark between the header label 
and the first block of records on each reel of tape 
is recommended, but not required. (If a tape 
mark follows a nonstandard header label the iocs 
will assume that end of file has been reached. 
However, the programmer may circumvent this 
condition by taking a label exit and issuing an 
rtlbl macro-instruction. ) 
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rdlin if the RDLfisr macro-instruction is used in the 
program. 
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Figure 37 

The entry in Figure 37 indicates that: 

1. The program uses only standard ibm tape labels. 

2. The program contains one or more files which re- 
quire only a check of the header label's identifica- 
tion field. 

3. None of the header labels are to be completely 
checked. 
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Figure 38 

The entry in Figure 38 indicates that some files of 
the program have standard labels and that some files 
have either nonstandard or no labels. The entry further 
indicates that one or more tape files have a tape mark 
between the header label and the first block of records 
and that the rdlin macro-instruction is used in the pro- 
gram. 

ALTDRIVE 

This entry is not needed if none of the tape files used by 
the object program are to be provided with alternate 
tape units. The operand of the altdrive entry is: 

yes if any of the tape files are to be provided with 
alternate tape units. 
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Figure 39 

The entry in Figure 39 indicates that one or more 
tape files used by the program are to be provided 
with alternate tape units. 

The assignment of an alternate tape unit to a multi- 
reel file can save a considerable amount of processing 
time. 

If no alternate tape unit is ass-igned to a multi-reel file, 
processing halts each time an end-of-reel condition 
occurs so that the operator can mount the next reel of 
tape. 

If an alternate tape unit is assigned, the operator 
mounts the second reel of the multi-reel file on the alter- 



nate unit. The iocs provides the necessary coding to 
continue the input or output operation via the alternate 
tape unit when the first end-of-reel condition occurs or 
the feorl macro is executed, and processing continues 
without interruption. 

Succeeding reels of the multi-reel file are then alter- 
nated between the initial and the alternate tape unit 
assigned to the file. The operator mounts successive 
reels on the tape unit to which the iocs will switch the 
i/o operation at the next end-of-reel condition, and 
processing continues without interruption. 

EXITS 

This entry is not needed if no exits are used by the 
programmer for specialized label handling. (See the 
section "The Eight iocs Exits." ) 

The operand of the exits entry consists of the num- 
ber(s) of the special exit(s) to be used by any of the 
files. The operands must be separated by commas and 
may be listed in any order. 
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Figure 40 

The entry in Figure 40 indicates that the program 
uses exits 1, 5, and 7. 

COUNTS 

This entry is required if any of the files used by the 
program require record counts or hash totals. The pos- 
sible operands of the counts entry are: 

record if any files require record counts. 

hash if any files require hash totals. 
If both operands are supplied they must be separated 
by commas, and may be listed in any order. 
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Figure 41 

The entry in Figure 41 indicates that a record count 
and a hash total are required by at least one file of the 
program. ( Block counts are taken and inserted into the 
trailer label automatically by the iocs. ) 

RWDOPTION 

This entry is not needed if: 

1. The object program uses no tape files. 

2. All tape files used by the program are to be re- 
wound but not unloaded when the file is opened 
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and closed, and when end-of-reel and end-of-file 

conditions are encountered. 
The operand of the rwdoption entry can be either 
norwd or unload, as shown in Figures 42 and 43. 
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Figure 43 

The unload operand provides the coding required to 
rewind and to unload tape files, but it leaves the pro- 
grammer free to utilize only part of, none, or all of the 
coding provided. Thus, having specified unload, the 
programmer can freely use tape files which are to be 
rewound and unloaded, merely rewound, or neither. 

The norwd operand provides the coding required to 
eliminate the otherwise automatic rewind that is given 
when a file is opened and closed, and when end-of-file 
and end-of-reel conditions occur. ( The coding provided 
by this operand is part of the coding provided by the 
unload operand.) 

Note that the diocs rwdoption entry is related to the 
dtf rewind entry (described later in this publication). 
That dtf entry can be used to specify whether a par- 
ticular file is to make use of the coding provided by 
one of the operands of this diocs entry. 

READERROR 

This entry is needed if the object program uses tape 
files. The operands of the readerror entry are shown 
in Figure 46. If only the scan operand is specified 
(Figure 44) the iocs will generate a *scan routine. 
This routine examines the affected input block (Form 
2 and Form 4 data records) or the affected input re- 
cord (Form 1 and Form 3), high order to low order, 
and types out the location of asterisks. (Invalid char- 
acters entering core storage during read operations 
are converted into asterisks if the asterisk insert 
switch is set to on. ) ( See IBM 1410 Principles of Op- 
eration, Form A22-0526. ) 
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If a read error occurs, a message is printed on the con- 
sole typewriter by the iocs and a waiting loop is estab- 
lished. The operator then has four options. He may enter 
the code word *scan for an asterisk scan of the affected 
block or record. He may enter the code word proc to 
process the block or record. He may enter the code 
word retry to retry the read operation, or he may enter 
the code word skip to skip the block or record. 
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Figure 45 

If only the tape,cu operand is specified ( Figure 45 ) , 
the iocs will generate a dump routine. This routine 
writes the affected block on the tape specified by cu, 
where c is the channel and u is the tape unit. No *scan 
routine is generated. 

If a read error occurs, the dump routine is auto- 
matically executed and a message is printed on the con- 
sole typewriter by the iocs. No options are available 
unless the user has modified iocseroptn. 

The character c of the cu operand may be 2 for chan- 
nel 2 only if all tapes to be read or written by the object 
program are to be read or written on channel 2. Other- 
wise, this entry must be 1 for channel 1. 
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Figure 46 

If both scan and tape,cu operands are specified 
( Figure 46 ) , a *scan and a dump routine are generated 
by the iocs. If a read error occurs, a message is printed 
on the console typewriter and a waiting loop is estab- 
lished. The machine operator then has five options. He 
may enter any of the following code words: dump, 
*scan, proc, retry, and skip. 

scan must precede the tape,cu operand. The scan 
and tape,cu operands must be separated by a comma. 

The tape file specified in the operand need not be 
defined by a set of dtf entries. A set, however, may be 
written. This would be especially valuable if the pro- 
grammer wished to check tape labels. 

If the *scan or the dump option is executed, the iocs 
again enters a waiting loop and writes the same mes- 
sage, thereby allowing the machine operator to con- 
tinue processing by selecting another option. 

If the readerror entry is omitted, *scan and dump 
routines are not generated by the iocs. If a read error 
occurs, a message is printed on the console typewriter 
by the iocs, and a waiting loop is established. The ma- 
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chine operator then has three options. He may enter 
any of the following code words: proc, retry, and skip. 

THE READ-ERROR OPTION CONTROL FIELD 

This field is generated during the Autocoder assembly 
of the object program, but may be modified by the user 
at any time. It is a six-character field labeled iocseroptn. 
The label addresses the low-order position of the field. 
This field, depending on the readerror operand or 
operands specified, will have one of the formats shown 
below: 

1. scan operand only, @b*SRPb@. 

2. tape,cu operand only, @DbsRPD@. 

3. scan and tape,cu operands both specified, 

@D*SRPb@. 

4. If the readerror entry is omitted, this field will 
have the following format: @bbsRpb@. 

In the formats shown, a low-order D indicates an 
automatic dump will occur. P stands for the code word 
proc. R stands for the code word retry. S stands for 
the code word skip, * stands for the code word *scan, 
and a high-order D stands for the code word dump. 

PRIORITY 

The priority entry indicates to the iocs how the user 
wishes to use the iocs Priority Assignment Routine. 
(The Priority Assignment Routine controls the order 
in which the file schedulers are arranged. It is this 
order of arrangement that in turn determines the 
priority of input/output requests for the files.) This 
entry may be omitted if the object program meets both 
of the following conditions : 

1. All two-area tape files are opened by the first open 
macro-instruction (one-area files may be opened 
at any time ) . 

2. No post-assembly modifications are made to any 
file's channel or priority assignments after the first 
open macro-instruction. (If the priority entry is 
omitted, changes to drive assignments may be 
made at any time. ) 

If the priority entry is omitted, the iocs overlays the 
Priority Assignment Routine after the first open macro- 
instruction is encountered in the object program. 

Any one of three entries is used in the operand field 
of this entry. 

1. NONOVERLAY 

If this operand is used, the iocs does not overlay the 
Priority Assignment Routine. All tape files may be 
opened at any time during the running of the object 
program, and post-assembly modification of channel, 
drive and priority assignments can be made at any time. 

2. nonoverlay, origin 

The "origin" is the five-digit address of a location where 



the programmer wishes the iocs to place the Priority 
Assignment Routine. 

If this operand is used, the iocs generates the Priority 
Assignment Routine starting at the specified origin 
address and, of course, does not overlay the routine. 

This operand allows the programmer to overlay the 
Priority Assignment Routine at a time most convenient 
to his program. Two-area tape files cannot be opened 
after this routine is overlaid; neither the channel, nor 
the priority, nor the drive of any tape files can be 
changed after the routine is overlaid. 

3. ASSEMBLE 

If this operand is used, the iocs does not generate a 
Priority Assignment Routine for the object program. 
The iocs assigns file priority according to the order in 
which the sets of dtf entries are arranged in the source 
deck. (This effects a saving of approximately 500 core- 
storage positions.) Although all tape files may be 
opened at any time, neither the channel nor the priority 
assignments can be changed after assembly. ( Drive as- 
signments, however, can be changed at any time. ) 

The programmer need not include priority assemble 
in his diocs entries to suppress generation of the priority 
assignment routine if no dtf entries are included in the 
source program. The omission of dtf entries in the 
source program will suppress generation of this routine. 

CHECKPOINT 

This entry is not needed if no checkpoint records are to 
be written. 

The operand of the checkpoint entry is a two-digit 
number. The first digit of this number indicates the 
channel; the second, the tape unit on which checkpoint 
records are to be written each time an end-of-reel condi- 
tion or a chkpt macro-instruction is encountered. 
Checkpoint records may be written on any of the output 
tapes. However, checkpoint records may not be written 
on reels of a tape file whose dtf entries include the 
alttape entry. 

If any input tape contains checkpoint records, the 
iocs will recognize and ignore them only if the dtf 
filetype entry for that particular tape input file con- 
tains the operand chkpt as well as the two other oper- 
ands tape and input. 

If any end-of-reel condition occurs during the writing 
of a checkpoint record, the tape is backspaced over the 
record that was just written, and no chkpt is written as 
a result of this macro-instruction. 

The tape unit specified by the operand can be one for 
which no file was defined by a set of dtf entries. If such 
a unit is specified, the user must insure that the tape is 
rewound to load point before the object program is 
executed, and that an end-of-reel condition will not 
occur. ( Since there are no dtf entries for the tape unit, 
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the iocs has no specifications for rewinding the tape or 
for end-of-reel procedure for that tape.) 

A set of dtf entries, however, may be written if the 
programmer wishes to check the labels of the tape on 
which the checkpoint records are to be written. If a dtf 
is written, the file should be opened, closed, etc., as if it 
were a normal file. 

Checkpoint records may not be written on odd parity 
data files. 
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Figure 47 

The entry in Figure 47 indicates that checkpoint 
records are to be taken each time an end-of-reel condi- 
tion or a chkpt macro-instruction is encountered, and 
that these records are to be written on tape unit 8 of 
channel 2. 



CHANCHANGE 

This entry is needed only if the programmer desires to 
modify a file's channel assignment after assembly. It is 
not needed if the programmer desires to modify only 
the drive, priority, mode or parity assignment. 

The operand of the chanchange entry is yes. See 
Figure 48. 
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Figure 48 

If the diocs chanchange entry is used with programs 
using the Overlap and Priority special features, approxi- 
mately 200 additional storage locations are required. 

The additional storage requirement for programs that 
do not use the Overlap and Priority special features is 
negligible. 

The chanchange entry cannot be used if the diocs 
priority assemble entry is used. 



INQUIRY 

URREuUEST 

UR2REQUEST 

These entries are provided to facilitate interrupt pro- 
gramming. The operand of the inquiry entry ( Figure 
49) is the label of a routine the user has written to 
service interrupts caused by depressing the Inquiry Re- 
quest Key on the ibm 1415 Console. 
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Figure 49 



The operand of the urrequest entry ( Figure 50 ) is 
the label of a routine the user has written to service in- 
terrupts from unit record equipment attached to chan- 
nel 1. 
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Figure 50 

The operand of the ur2request entry ( Figure 51 ) is 
the label of a routine the user has written to service 
interrupts from unit-record equipment attached to 
channel 2. 
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Figure 51 

The interrupts these routines service occur upon: (a) 
the completion of the transfer of a group of data from 
an ibm 1402 Card Read Punch or an ibm 1011 Paper 
Tape Reader to the appropriate buffer in the ibm 1414 
Input/Output Synchronizer, or (b) the completion of 
the transfer of a group of data from the buffer in the ibm 

1414 Input/Output Synchronizer to an ibm 1402 Card 
Read Punch or an ibm 1403 Printer. 

To obtain the unit-record equipment interrupts dis- 
cussed above, the Priority Select Switch on the ibm 

1415 Console must be turned to card reader, card 

PUNCH, PRINTER, Or PAPER TAPE READER (whichever is 

appropriate), and the appropriate Priority Select On- 
Off Key must be depressed. 

ACTION OF THE IOCS 

When a console inquiry or unit-record interrupt occurs, 
the iocs determines whether the relevant user's routine 
is servicing a previous interrupt. If the users routine is 
not servicing a previous interrupt the iocs: (a) saves 
the status of the High-Low-Equal and Zero Balance 
Indicators, the contents of index registers 13, 14 and 
15, and associates this information with the user's rou- 
tine; (b) saves the return address to the interrupted 
instruction and associates it with the user's routine; (c) 
leaves clear the appropriate channel by insuring that 
the next input/output operation scheduled for execu- 



o 



o 



Q 



24 



tion on that channel is not initiated; and (d) causes a 
branch that removes the program from Priority Alert to 
be executed to the user's routine. If the user's routine is 
servicing a previous interrupt, the iocs simply causes a 
branch to be executed in the noninterruptible mode to 
the user's routine. 

Re-entry into the user's unit record interrupt routine 
may occur if a get or put is issued against a unit-record 
file within the user's unit-record interrupt routine. Re- 
entry into the user's console inquiry interrupt routine 
may occur if any iocs macro-instruction except iosys is 
issued within the user's console inquiry interrupt 
routine. 



ACTION OF THE USERS ROUTINE 

User-written routines that service console inquiry and 
unit-record interrupts must conform to the program- 
ming scheme illustrated in Figure 52 and discussed 
below. The steps of the suggested programming scheme 
for user-written interrupt routines is as follows: 

1. A switch, hereafter referred to as the Nest Switch, 
is tested. 

2. If the Nest Switch is on (indicating that the rou- 
tine is servicing a previous interrupt) the fact that an- 
other interrupt has occurred (to be serviced by the 
routine ) is noted, and a branch that removes the pro- 
gram from Priority Alert ( bxpa ) is executed to an ad- 
dress labeled $cs1ent. 

If the current interrupt originated from the console 
printer, the printer must be read into an alternate area 
( i.e., an area other than the area into which the routine 
normally reads the console printer) by means of the 
consl macro-instruction before the branch is executed 
to $cs!ent. 

If the current interrupt originated from the console 
printer, the user's interrupt routine must not disturb the 
contents at index registers 13-15. 

3. If the Nest Switch is off (indicating that the rou- 
tine is free to service the current interrupt), routines 
that service console inquiry interrupts must read the 
console printer by means of the consl macro-instruc- 
tion, and routines that service unit-record interrupts 
should issue a get macro-instruction against the file 
which refers to the unit-record device from which the 
interrupt originated. 
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Figure 52 

If two or more get macro-instructions are issued 
against the file, the sequence of instructions shown in 
Figure 53 must precede all but the first get macro- 
instruction. 

4. Once Step 3 has been executed, the routine can 
process the information obtained by the appropriate 
macro-instruction as the programmer sees fit (i.e., serv- 
ice the interrupt ) . 

5. When this information has been processed, a check 
is made to determine if another interrupt ( to be serv- 
iced by the routine ) has been noted. 
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6. If another interrupt has been noted, the note is 
erased and a branch is executed to the macro-instruc- 
tion in Step 3. 

7. If another interrupt has not been noted, the pro- 
gram is taken out of Priority Alert (the macro-instruc- 
tion issued in Step 3 caused the program to be placed in 
Priority Alert) by means of the instruction bxpa * + l; 
the Nest Switch is set off, and a branch (bxpa) is exe- 
cuted to the address labeled $csnEl-f 7. (The n in the 
label $csnEl-f7 represents the channel from which the 
interrupt originated. ) 



The DTF Entries 

In addition to the diocs entries, the programmer who 
wishes to use the Input/Output Control System should 
write one set of dtf (Define The File) entries for each 
file ( magnetic tape, and unit-record file ) used by his 
program. Depending on installation features and the 
program, this information consists of three or more 
entries listed individually on the ibm 1401/1410 Auto- 
coder Coding Sheet. 

Each set of dtf entries describes the characteristics 
of the file for which it was written, and indicates the 
methods to be used by the iocs in handling the file. 
Using the information supplied in the dtf entries, 'the 
Autocoder Processor develops the File Scheduler and 
the coding required for the proper handling of each file. 

Note: If the programmer does not include any dtf 
entries in his source program, a minimal iocs will be 
generated. The open, close, get, and put macro-in- 
structions cannot be used if a minimal iocs is generated. 
All other macro-instructions can be used. 

General Format 

The first dtf entry consists of the code dtf in the opera- 
tion field, followed by the name of the file in the 
operand field. All subsequent dtf entries have blank 
operation fields and must have the labels listed below. 
All dtf entries may be followed by comments which 
must be separated from the dtf entries by at least two 
adjacent blanks. The entries following the header line 
may be listed in any order. 

All operands of dtf entries may use address modifica- 
tion provided the label consists of no more than 13 
characters (i.e., label+110 is a valid label if label 
consists of no more than nine characters ). 

All symbolic operands of dtf entries, except those of 
input/output areas, may be indexed. 

The dtf, filetype and ioareas entries are mandatory. 
The remaining entries are not always required. 



The set of dtf cards enters the system immediately 
after the diocs cards during Autocoder assembly, dtf 
cards without operands are not permitted. Each dtf 
entry is described below, under a sub-heading indicat- 
ing the label of the entry. 



List of DTF Entries 

This section describes the 
the following dtf entries : 
dtf header line 

FILETYPE 

PREFIX 

MODEPAR 

CHANDRIVE 

CARDPOC 

ALTTAPE 

RECFORM 

SIZEREC 

PADDING 

BLOCKSIZE 

IOAREAS 

WORKAREA 

INDEXREG 

PRIORITY 

EOFADDR 

WLRADDR 



function and use of each of 

TOTALS 

TYPELABEL 

CHECKLABEL 

HEADER 

SERIALNUM 

REELSEQ 

REWIND 

exIaddr 

ex2addr 

ex3addr 

ex4addr 

exSaddr 

ex6addr 

ex7addr 

ex8addr 

varbuild 

scheduler 



The DTF Header Line 

The first dtf entry is mandatory and consists of the entry 
dtf in the operation field, followed by the name of the 
file in the operand field. It is known as the dtf header 
line ( Figure 54 ) . 
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FILETYPE 

The filetype entry is mandatory. It specifies the type of 
input/output device used by the file and whether it is 
used for input or output. The operands of the filetype 
entry are: 

tape if the file described by the dtf is a tape file. 
reader if the file described by the dtf is a card input 

file. 
punch if the file described by the dtf is a card output 

file. 
printer if the file described by the dtf is a printer 

output file. 
input if the file described by the dtf is a tape input 
file. 
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output if the file described by the dtf is a tape output 

file. 
chan2 if the file described by the dtf is read or 

written by the 1402 Card Read Punch (or the 1403 

Printer ) attached to channel 2. 
chkpt if this file also contains checkpoint records from 

a previous run; this would be the case if this tape 

had served also as the checkpoint tape on the run 

during which it was created. 
The operands input and output are not required for 
unit record files. 
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Figure 58 
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Figure 57 

The entry in Figure 55 indicates that the dtf de- 
scribes a tape output file. The entry in Figure 56 indi- 
cates that the dtf describes a punch ( and hence an out- 
put) file. The entry in Figure 57 indicates that the file 
described by this dtf is a card input file that will be 
read by the 1402 Card Read Punch attached to chan- 
nel. 

PREFIX 

This entry is required if two files reference the same 
tape unit, 1402 Card Read Punch, or 1403 Printer. The 
operand is xx, where xx can be any two letters ( except 
er ) that are not used by other prefix operands. 

This entry insures that the File Schedulers associated 
with these files will not have the same label. 

Figure 58 illustrates the use of the prefix entry to 
define two files that refer to the same i/o unit. Lines 
01-09x define two files that refer to tape unit 3 on chan- 
nel 1. Lines 10-16x define two files that refer to the 1403 
Printer on channel 2. File Scheduler labels for inwkfl 
will have the format iocs13label. The labels for 
outwkfl will have the format iocsaalabel. Similarly, 
the File Scheduler labels for the channel 2 printer files 
will be iocs2llabel and iocszzlabel. ( Autocoder desig- 
nation for the 1403 Printer is the letter l. ) 



MODEPAR 

This entry is not needed for unit record files or for tape 
files which are to be read or written in the move mode 
and which use even parity. ( See comments regarding 
the move and load modes and parity considerations 
that follow. ) 

The operands of the modepar entry are: 

load if the tape file described by the dtf is to be 

read or written in the load mode. 
odd if the tape file described by the dtf is to be 
read or written in odd parity. 
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Figure 62 

The entry in Figure 59 indicates that the tape file 
described by this dtf is to be read or written in the 
load mode and in odd parity. The entry in Figure 60 
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indicates that the file is to be read or written in the load 
mode, using even parity. The entry in Figure 61 indi- 
cates that the file is to be read or written in the move 
mode and in odd parity. The entry in Figure 62 indi- 
cates that the file is to be read or written in the move 
mode, using odd parity. 

Note : The operands move and even may be entered 
but are not needed. 
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Figure 63 

The entry in Figure 63 indicates that the file is to be 
read or written in the move mode and in even parity. 
The entjre entry could have been omitted since a file is 
assumed to be read or written in the move mode and in 
even parity unless otherwise specified. 



LOAD MODE VS. MOVE MODE 

LOAD Mode: The handling of word marks and word 
separator characters varies with the type of operation 
as follows: During write or punch operations, each 
word mark is translated into a word separator character 
which precedes the character with which the word mark 
was associated in storage, and each word separator 
character is translated into two word separator 
characters. During read operations, word marks already 
in the input area are cleared. Each word separator 
character is translated into a word mark, and each pair 
of word separator characters is translated into a word 
separator character. 

MOVE Mode: When information is read or written 
in the move mode, all 64 bcd characters are read or writ- 
ten. Word marks in storage are undisturbed, but they 
are not written out as word separator characters during 
write operations. Word separator characters are entered 
in storage and written out as word separator characters. 



PARITY CONSIDERATIONS 

In order to insure compatability with other ibm sys- 
tems, the ibm 1410 can read and write tapes in either 
even or odd parity, with one exception: on even parity 
tapes, the cent sign (<£) and the blank (b) are repre- 
sented by the same bcd configuration (i.e., ca). When- 
ever this ca configuration is read into core storage 
from an even parity tape, it will be stored as a C-bit 
(blank) and not as an A-bit (cent sign). 

In choosing tape parity for a given application, the 
programmer should consider the effect of the above on 
his program. 



CHANDRIVE 

This entry is not needed for unit-record files. The 
operand of the chandrive entry is: 

xy where x is the initial channel and y is the initial 
tape unit described by the dtf. 
If two or more sets of dtf entries use the same 
chandrive operand, a dtf prefix entry must be written 
for all but one of them. 
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Figure 64 

The entry in Figure 64 indicates that the initial tape 
unit described by this dtf entry is unit 7 of channel 2. 

Files should be assigned to channels in such a manner 
that the time during which the channels are used dur- 
ing the running of the program is approximately the 
same for both channels. When reading and writing 
times are nearly equal, it is usually advisable to assign 
output files to one channel and input files to the other. 

CARDPOC 

This entry is required when card files are used. The 
operands of the cardpoc entry are: 

x where x is one digit (0, 1, 2, 4 or 8) and indicates 
the card pocket into which cards from this file 
are to be selected. 
9 if the programmer uses the stack macro-instruc- 
tion for his card file. 
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Figure 66 

The entry in Figure 65 indicates that all cards from 
this file are to be selected into pocket 8 of the card 
punch. The entry in Figure 66 indicates that the pro- 
gram uses a separate stack macro-instruction command 
for each card of this file. 

ALTTAPE 

This entry is not needed if no alternate tape unit is re- 
quired for this file. (See section on Alternate Tape 
Units.) The operand of the alttape entry is: 
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x where x is one digit representing the number of 
the alternate tape unit. 
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Figure 67 

The entry in Figure 67 indicates that tape unit 5 of 
the tape channel specified by the chandrive entry of 
this dtf will be used as the alternate tape unit. 

RECFORM 

This entry is not needed for files containing fixed- 
length, unblocked records. The operands of the 
recform entry are: 

variable if the file described by the dtf consists of 
variable-length records. 

blocked if the records described by the dtf are 
blocked. 
The operands must be separated by a comma, and may 
appear in any order. The operands fixed and 
unblocked, referring to fixed-length and unblocked 
records, respectively, may be used but are not required. 

RECORD FORMATS HANDLED BY THE 1410 IOCS 

Records made available by the get macro-instruction 
must always have a record mark or a group mark with 
word mark in the low-order position if the iocs is to 
move them from one location in core storage to another. 
Form 1 Records: These are fixed-length, unblocked 
records, as shown in Figure 68. 
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Figure 68. 



Form 2 Records: These are fixed-length, blocked 
records with padding of short-length blocks, as shown 
in Figure 69. If necessary, blocks consisting of fixed- 



length records are padded — either with the character 
specified in the dtf padding entry or with blanks if the 
padding entry was omitted. The user should insure that 
padding records are not mistakenly processed as data 
records. Padding records may be bypassed by issuing 
consecutive get macro-instructions until an end-of-file 
indication is obtained. 




Figure 69 



un- 



Form 3 Records: These are variable-length, 
blocked records, as shown in Figure 70. 

The area defined by the DA statement must be large 
enough to handle the largest records. When the record 
is processed, the entire area is moved; that is, the rec- 
ords are handled as though they were fixed-length 
records. 
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Figure 70 








Without Record Marks 



Form 4 Records: These records are variable-length, 
blocked, with a block character count field at the be- 
ginning of each block, and a record character count 
field in each record (see Figure 71). Each block has a 
variable number of variable-length records. 

Block Character Count Field: A four-character block 
character count field at the beginning of each block 
contains a count of the total number of characters in the 
block, including the four-character block character 
count field, itself. (Terminal group marks with word 
marks are not included in this count. ) The block charac- 
ter count field has ab zone bits over the units position. 
The count is used for checking and correcting wrong- 
length-record conditions. 

Record Character Count Field: A record character 
count field of up to four characters in each record con- 
tains a count of the number of characters in that record, 
including itself and the record mark (if appropriate). 
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NOTE: The maximum size of blocks permissible is 9999 positions. 

Figure 72. Summary of Record Formats 
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The high-order position of this field must have a word 
mark. The maximum size of blocks permissible is 9,999 
positions. See Figure 72. 



EXAMPLES OF RECFORM ENTRIES 
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Figure 73 

The entry in Figure 73 indicates that this file consists 
of Form 2 (i.e., fixed-length, blocked) records. The 
same dtf statement could have been written as shown 
in Figure 74. 
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Figure 74 

As indicated above, records are assumed to be fixed- 
length, unblocked records, unless otherwise specified. 
The entries fixed and unblocked may, therefore, be 
omitted. 

SELECTING THE TAPE RECORD FORMAT 

The time required to complete most data processing 
operations depends largely on the tape time, i.e., the 
time required to read and write tape records. A certain 
amount of time is needed to start and stop the tape 
each time a tape record is read or written. If this start- 
ing and stopping time is shared by 20 records of a 20- 
record block, the start-stop time per record is l/20th of 
that required if the 20 records were placed on tape 
individually. An effective method of reducing the total 
job time, therefore, is to place tape records in groups 
or blocks. 



When selecting the format of tape records, the pro- 
grammer should give serious consideration to record 
blocking. Because record blocking and deblocking is 
handled by the iocs, blocking of records does not re- 
quire additional programming effort. 

SIZEREC 

This entry is not needed for files containing unblocked 
records. 

VARIABLE-LENGTH, BLOCKED RECORDS 

The operand of the sizerec entry is: 

n where n indicates that the low-order position of 
each record's character count field is the nth 
character of each record. 
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Figure 75 

The entry in Figure 75 indicates that the low-order 
position of the character count field in each record of 
this file is the tenth position of the record. See also 
Figure 76. 

fixed-length, blocked records 

The operand is: 

m where m is the number of characters in the 
record, including the record mark. (Thus, the 
operand is 80 for 80-character records.) 

PADDING 

This entry is needed only for output and work files 
containing fixed-length, blocked records. The operand 
of the padding entry is: 

x where x is the character with which the block is 
to be padded. 
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Figure 76. The Record Character Count Field 



The following characters may not be used for padding: 
asterisk, tape mark, word separator character, record 
mark, cent sign and group mark. 
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Figure 77 

The entry in Figure 77 indicates that partially filled 
blocks are to be padded with the digit 7. 

Padded records are included in the record count 
and padding is added to the hash total. 

If the padding entry is omitted, partially filled blocks 
of this record type will be padded with blanks. 

BLOCKSIZE 

This entry is required for all files except those which 
consist of unblocked, variable-length records if check- 
point records are not to be bypassed. If checkpoint 
records are to be bypassed, the dtf blocksize entry is 
not required for files which consist of unblocked fixed- 
length records. The operand of the blocksize entry is: 
x where x is the number of positions of the input 
or output area of the file defined by this dtf. 
The group mark with word mark terminating the i/o 
area is not included in this count. 
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Figure 78 

The entry in Figure 78 indicates that the file defined 
by this dtf has 2,000-character input or output area ( s ) . 
( If two input or output areas are used, each has 2,000 
characters. ) 

IOAREAS 

This entry is mandatory. The operand of the ioareas 
entry consists of the label(s) assigned to the input (or 
output ) area( s ) of the file described by the dtf. If there 



are two areas, the two labels of these areas must be 
separated by a comma. 

If only one input or output area is specified, the label 
of that area may be indexed, provided the records to be 
processed in this area are not blocked. 

Overlapping of input/output operations with process- 
ing is possible only for tape files that have two input/ 
output areas (i.e., files whose dtf ioareas entries have 
two operands). The 1410 iocs does not permit unit 
record files to have two input/output areas. 
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Figure 79 

The entry in Figure 79 indicates that the input (or 
output ) areas of the file described by this dtf are those 
defined by da's labeled labelI and label2, respectively. 

ADVANTAGES OF TWO i/o AREAS 

Substantial savings in processing time are possible if 
the 1410 system is equipped with the Overlap and 
Priority special features. This permits the use of two 
input/output areas and makes possible complete over- 
lapping of input/output operations and processing. The 
following considerations apply. 

1. If the Overlap special feature is not used, only one 
input/output area can be used. 

Input: Record blocks are deblocked by the iocs, i.e., 
logical records are successively made available for 
processing, one after the other, until all records in the 
input area have been processed. Processing then 
halts while the next block of records is read in, where- 
upon processing resumes. 
Output: In the case of output areas, the iocs blocks the 
records, and each time the building of a block of 
records has been completed, processing halts to per- 
mit writing out of the completed block. Only after 
the output area has been emptied can processing — 
and building of the next block of records — be 
resumed. 
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2. If the Overlap special feature is used, two input/ 

output areas can be used: 

Input: Logical records are processed successively, one 
after the other. When all records in Input Area I have 
been processed, the iocs makes the records in Input 
Area II available to the processor (Figure 80). 
Processing does not stop. While logical records are 
being taken successively from Input Area II, the iocs 
arranges for Input Area I to be refilled with records. 
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When all logical records in Input Area II have been 
processed, the iocs makes the new records in Input 
Area I available to the processor, refills Input Area 
II, and so forth. In this manner, input operations and 
processing take place simultaneously, resulting in 
greater utilization of the computer system. 
Output: The same considerations apply to two output 
areas : processing and building of record blocks con- 
tinue in one area while a completed block in the other 
area is written out. In this manner, output operations 
and processing also take place simultaneously. 



WORKAREA 

This entry is not needed for files which do not use a 
work area or which use the dtf indexreg entry. The 
operand of the workarea entry is the label of the work 
area used by the input or work file. 



INDEXREG 

This entry is not needed if no index register has been 
assigned to the file described by the dtf. The operands 
of the indexreg entry are; 

XI, X2, , X14, indicating the index 

register assigned to the file. 
Index register 15 may not be assigned to a file, although 
it may be used for other purposes. 



PRIORITY 

This entry is not needed for files of programs which do 
not use the Priority special feature, nor is it used if the 
diocs priority assemble entry is used with the program. 



The operands of the priority entry are: 

to indicate highest priority 

1 to indicate next-to-highest priority 
2 



9 to indicate lowest priority 
The operand indicates the relative priority of the file 
described by the dtf on the channel specified by the 
chandrive entry of the dtf. 

Files of greatest activity should be assigned highest 
(i.e., 0) priority. 

Files for which the dtf priority entry is omitted will 
be assigned lowest (i.e., 9) priority. (If the diocs pri- 
ority assemble entry is used, the iocs assigns file pri- 
ority according to the order in which the sets of dtf 
entries are arranged in the source deck. ) 

EOFADDR 

This entry is needed only for input files, including 
work files used as input files. 

The operand of the eofaddr entry is the label of the 
end-of-file routine written by the programmer. If the 
file is a unit-record file, the get following the get that 
caused the last card of the file to be read will sense the 
fact that an end-of-file condition has occurred and cause 
a branch to be taken to the user's end-of-file routine. If 
the file is a tape file that does not use labels, the sensing 
of a tape mark will cause the iocs to branch to the users 
end-of-file routine. If the file is a tape file that uses 
labels, lEOFb in a trailer label will cause the iocs to 
exit to the user's end-of-file routine. 

WLRADDR 

This entry is not needed for output files and for vari- 
able-length, unblocked input files. The operand of the 
wlraddr entry is the label of the wrong-length-record 
routine written by the programmer. 

If this entry is omitted, a wrong-length-record check 
will not be made. Wrong-length-record checks will not 
be made for variable-length, unblocked files. In his own 
routine, the programmer may give any i/o commands 
except get macro-instructions to the affected file. 

Each time a wrong-length-record condition occurs, 
the iocs will retry reading the record nine times. If the 
block remains in error, the iocs will branch to the pro- 
grammer's routine labeled wlraddr, in which the pro- 
grammer may either attempt to correct the block or 
dump it. 

If a wrong-length-record condition occurs, the iocs 
will always branch to the address represented by 
wlraddr. If there are two areas used by the file, the 
iocs will use a location labeled iocscuiob to indicate in 
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which area the error condition occurred. If the error 
was in the first area (the area defined by the first 
operand of the dtf ioareas entry), the iocs will set a 
word mark at iocscuiob. If the error occurred in the 
second area, the iocs will clear the word mark at 
iocscuiob. (The cu is the channel and unit number of 
the tape file, unless a dtf prefix entry is used for the 
file, in which case the two letters specified by that 
entry replace the cu. ) 

If the file consists of Form 4 records, the length of the 
wrong-length record will be stored in an area labeled 
iocscublkl ( where cu is the channel and unit number 
of the tape file ) . If the file uses a dtf prefix entry, cu is 
replaced by the two letters specified by that entry. 

The programmer should use the first instruction of 
his wlraddr routine to store the contents of the B-Regis- 
ter. This will enable him to return control to the iocs at 
the end of his wlraddr routine. Assume the contents of 
the stored B-Register were X: 

If the programmer branches control to X, the iocs 
will process the corrected block. 

If the programmer branches control to X+7, the 
iocs will bypass processing of the faulty block. 



Record counts cannot be requested for tape files that 
consist of unblocked records. 

The entry in Figure 81 indicates that hash total 
counts are to be taken from the field shown in Figure 82. 

Hash total fields may contain any alphameric in- 
formation, but must not be larger than ten characters. 
A word mark must define the high-order position of the 
field. Hash totals cannot be requested for unit record 
files. 

TYPELABEL 

This entry is not needed if the file described by the dtf 

has no labels. The operands of the typelabel entry are: 

standard if the file described by the dtf uses ibm 

standard labels. 
nonstandard if the file described by the dtf uses 

nonstandard labels. 
tm if the file has a tape mark between the header 
label and the first block of records. 
If two operands are used, they must be separated by a 
comma. They may be entered in any order. See 
Figure 83. 



TOTALS 

This entry is not needed if a record count or a hash 
total is not to be inserted in the trailer label. The 
operands of the totals entry are: 

record if a record count is desired, 
x where x is the address of the low-order position 
of the count field ( from which hash total counts 
are to be taken ) relative to the high-order posi- 
tion of the record. See Figures 81 and 82. 
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Figure 81 
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Figure 83 



CHECKLABEL 



This entry is not needed if standard labels are not used 
or if labels are not to be checked. The operands of the 
checklabel entry are: 

all if header and trailer labels are to be completely 

checked. 
ident if trailer labels are to be completely checked, 
but if only the ten-character file identification 
name of the header label is to be checked. 

Tape Labels 

This section describes the ibm 1410 tape labels under 
four topics : 

The purpose of tape labels 
Recommended tape labeling practices 
Standard ibm tape labels 
Use of tape labels by the iocs 

purpose of tape labels 

The 1410 Input/Output Control System uses standard 
ibm header and trailer labels to insure proper handling 
of input and output files during the running of 1410 
programs. 

Header Labels: The iocs can read and check tape 
header labels to insure that the object program uses the 
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proper tapes. (If no check of header labels is to be 
made, output header labels are not read. ) 

Before writing a new output file, the iocs checks for 
the existence of a header flag, LHDRb, then checks the 
output tape's retention cycle (i.e., the period of time 
following its creation during which the file may not be 
destroyed ) . If the current date falls within the retention 
cycle, the iocs informs the operator via an appropriate 
message (printed on the console printer) that an at- 
tempt was made to write on a file protected by an unex- 
pired retention cycle. 

Trailer Labels: The iocs can check input trailer labels 
to insure that all information in the file has been proc- 
essed and to indicate end-of-reel and end-of-file condi- 
tions. The iocs can also write trailer labels for output 
files to provide the checking functions just described 
when the output files are later used as input files. (A 
tape mark, the trailer label, and another tape mark 
form the last three records of each tape, in that order. ) 

IOCS Label Checking and Label Writing Functions: 
All tape handling errors discovered by the iocs are 
called to the attention of the operator by appropriate 
messages printed on the console printer. If necessary, 
the program is halted to enable the operator to take cor- 
rective action. The label checking and label writing 
functions offered by the iocs are summarized in 
Figure 90. 

RECOMMENDED TAPE LABELING PRACTICES 

Temporary Labeling: A temporary header label fol- 
lowed by a tape mark should be placed on each tape, 
until it is used as a data or program tape. This labeling 
may be done by means of the ibm 1410 Tape File Gen- 
erator utility program, or by off-line equipment. 

Temporary Header Labels: Temporary header labels 
should have the format indicated in Figure 84. 



Field No. 


Positions 


Contents 


Description 


1 


1-5 


lHDRb 


Header Label Identifier 


2 


6-10 


xxxxx 


Tape Serial Number 


3 


11-80 


blank 


May be used as desired 
by the programmer 



Figure 84. Temporary Header Label 

Tape Serial Number: The tape serial number ( Field 
2) is a five-digit number (00001-99999) assigned con- 
secutively to tapes entering the 1410 system. After tapes 
have been labeled, permanent physical labels should be 
placed on each reel indicating the date the tape entered 
the system, the serial number assigned, and the density 
in which the tape is to be written. The physical label 
should not be removed until the tape is retired from 
the system. 



IBM STANDARD TAPE LABELS 

Standard ibm tape labels have 80 characters. They are 
written in even parity and in the move mode, and they 
are read in even parity and in the load mode. 

Standard Header Label: The ibm standard header 
label (Figure 85) consists of eight fields containing: 

1. A five-character header flag ( lHDRb ) , columns 1-5. 

2. A five-character tape serial number, columns 6-10. 

3. A five-character file serial number, columns 11-15. 

4. A five-character reel sequence number (-xxxb), 
columns 16-20. 

5. A ten-character file name, columns 21-30. ( The file 
name must consist of alphameric characters). 

6. A five-character creation date, columns 31-35. 

7. A five-character retention cycle, (-000b), columns 
36-40. 

8. A forty-position field that is blank if not filled in by 
the user, columns 41-80. This field may be used in 
any way desired by the programmer. 
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Figure 85. The Standard Header Label 
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The two high-order digits of the creation date indi- 
cate the year (00-99) and the remaining three digits 
the nth day of that year ( 001-366 ) on which the file was 
created. 

In the retention cycle field, the three-digit number 
following the minus sign indicates the number of days 
the file is to be preserved after the creation date. Files 
should be preserved until all output data created from 
them has been used successfully as new input. This in- 
sures that any record which requires the file as input 
can be reconstructed by means of a single run. Stand- 
ard header labels provide for retention cycles from one 
to 365 days. For files which are to be protected indefi- 
nitely, the programmer can insert the digits 99 in the 
two high-order positions of the creation date. 

Standard Trailer Label: The standard ibm trailer 
label consists of the following fields : 

1. A five-character trailer flag, lEOFb or lEORb, de- 
pending on whether the label indicates end-of-file 
or end-of-reel, columns 1-5. 

2. A five-character block count, columns 6-10. 

3. A ten-character record count, (optional), columns 
11-20. 

4. A ten-character hash total (optional), columns 
21-30 (or columns 11-20 if no record count is 
taken ) . 

5. A 50-position field that is blank if not filled in by 
the user, columns 31-80. This field may be used in 
any way desired by the programmer. 
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FOUR FORMATS OF THE STANDARD TRAILER LABEL 

1. If both record count and hash total are specified 
by the diocs counts entry, the standard trailer label con- 
tains the fields shown in Figure 86. 
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Figure 86 
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2. If neither record count nor hash total are specified 
by the diocs counts entry, the third and fourth fields 
(columns 11-30) contain blanks, as shown in Figure 87. 
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4. If only a record count is specified by the diocs 
counts entry, the third field (columns 11-20) contains 
the current record count, beginning with all zeros. The 
fourth field (columns 21-30) contains blanks. See Fig- 
ure 89. 



lEOFb 



lEORb 



BLOCK 
COUNT 



RECORD COUNT 



bbbbbbbbbb 



1 5 6 10 11 
Figure 89 



20 21 



30 31 



lEOFb 

or 
lEORb 



BLOCK 
COUNT 



bbbbbbbbbb 



bbbbbbbbbb 



1 



5 6 



10 11 



20 21 



30 31 



Figure 87 

3. If only a hash total is specified by the diocs counts 
entry, the third field (columns 11-20) contains the cur- 
rent hash total, beginning with all zeros. The fourth 
field (columns 21-30) contains blanks. See Figure 88. 



USE OF TAPE LABELS BY THE IOCS 

The label checking and label writing functions pro- 
vided by the 1410 IOCS are summarized in Figure 90. 

HEADER 

This entry is not needed if standard labels are not used 
or if labels are not to be checked. The operands of the 
header entry for input files and work files are: 
1. The ten-character file identication name. 
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For Input files/ the 
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program . 

For output files / the header 
label is used by the IOCS 
to check whether the file 
to be written on may be 
destroyed . 

The Trailer Label 

(except for the tape mark 
which follows it) is the last 
record on a tape file. It is 
used to check that all infor- 
mation in the files was pro- 
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end-of-reel and end-of -file 
conditions. 
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Output Header Label 
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from the old header label of 
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Output Trailer Label 

Write all or part of the 
new trailer label 



Figure 90. Use of Tape Labels by the iocs 
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2. The five-digit creation date. (For output files, the 
creation date is taken from storage positions 115- 
119, where it should be entered each day by means 
of a load card. Care should be used to preserve the 
word mark at location 115. ) 
The operands of the header entry for output files are: 

1. The ten-character file identification name. 

2. The three-digit retention cycle (in days). 

The operands must be listed in the order indicated, and 
must be separated by a comma. 
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Figure 91 
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The entry in Figure 91 indicates that this (input) file 
is named filenameIO, and was created on the sixth 
day of 1963. The entry in Figure 92 indicates that this 
(output) file is named filename20, and has a retention 
cycle of 60 days. 

SERIALNUM 

This card is not needed if: 

1. The file described by the dtf has no file serial 
number, or 

2. The file serial number is not to be checked, or 

3. The file serial number (of an output file) is equal 
to the tape serial number. 

The operand of the serialnum entry (Figure 93) is 
xxxxx where xxxxx is the standard five-digit file 
serial number. 
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If this entry is present, a check is made of the file 
serial number if the all operand of the checklabel 
entry has been specified. If this operand has not been 
specified, no check of the file serial number will be 
made. 



REELSEQ 

This entry is not needed if the first reel of the standard- 



label file described by this dtf is numbered 001. The 
operand of the reelseq entry is 

xxx where xxx is the three-digit alternate reel se- 
quence number assigned to the reel by the 
programmer. 
If the programmer assigns his own reel sequence 
number, he must modify it himself (by using an exit). 

REWIND 

This entry is not needed if: 

1. The file described by this dtf is not a tape, or 

2. The iocs is to rewind the tape for this file when 
the file is opened and closed, and when end-of- 
file and end-of-reel conditions occur. 

The operand of this entry can be either unload or 
norwd, as shown in Figures 94 and 95. 
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Figure 95 

unload specifies that the tape for this file is to be 
rewound and unloaded when the file is closed, and 
when end-of-file and end-of-reel conditions occur. 
( This operand can be used only if the diocs rwdoption 
entry, with the unload operand, is included in the 
program. ) 

norwd specifies that the tape for this file is never to 
be automatically rewound by the iocs. ( This operand 
can be used only if the diocs rwdoption entry, with 
either the unload or norwd operand, is included in 
the program. ) 

The Eight IOCS Exits 

None of the following eight ex.addr entries is needed if 
the programmer does not wish to modify the standard 
treatment of labels provided by the 1410 iocs. 

Each exit makes it possible to branch to a routine 
written by the programmer to modify the standard label 
handling treatment provided by the 1410 iocs. In each 
case, the last instruction of the modifying routine is a 
branch to iocsrentry which returns the program to the 
appropriate section of the iocs label handling routines. 
(For an exception, see the third paragraph under 
"ex6addr") 

The eight exits are located between different sections 
of the iocs label handling routines. The exits make it 
possible to bypass all or part of the iocs label handling 
routines, enabling the programmer to write his own 
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label handling routines. For example, the programmer 
can use one such exit (i.e., ex6addr) to perform addi- 
tional checking of standard input trailer labels. After 
completing his own specialized routine, the program- 
mer returns to the program by branching to the re-entry 
location, labeled iocsrentry. Standard labels are read 
into and written from an 80-character area whose 
high-order position is labeled iocslbarea. ( If the iocs 
Independent Assembly Feature is used, iocslbarea 
represents the low-order position of a 5-character field 
containing the address of the label area's high-order 
position. ) 

The operand of each of these dtf entries is the label 
of the specialized label handling routine written by the 
programmer. Eight exits are provided. 

EX1ADDR 

This exit permits the programmer to branch to his own 
routine in order to enter additional information into the 
output trailer label. 
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Figure 96 

The entry in Figure 96 indicates that the programmer 
wishes to enter additional information into output 
trailer labels by branching to his routine, ownlabel. 
The last instruction of this routine will be a branch to 
iocsrentry. The iocs will then continue all necessary 
subsequent label handling. 

EX2ADDR 

This exit permits the programmer to branch to a routine 
written to process nonstandard output trailer labels or 
to write labels that are in addition to the standard out- 
put trailer label. 

EX3ADDR 

This exit permits the programmer to branch to his own 
routine for the checking of standard output header 
labels. ( This checking will not be done by the iocs when 
Exit 3 is used. ) 

EX4ADDR 

This exit permits the programmer to branch to his own 
routine which will modify the standard (output) 
header labels to be written by the iocs. 

EX5ADDR 

This exit permits the programmer to branch to his own 
routine which will write nonstandard header labels or 
write output labels in addition to the standard header 
label. 



EX6ADDR 

This exit permits the programmer to branch to his own 
routine which will perform additional checking of 
standard input trailer labels and/or additional input 
trailer labels or nonstandard input trailer labels. 

This exit may be used to modify the reel sequence 
count and/or the dtf rewind entry. (See Tape File 
Table, under "Additional Information for Program- 
mers.") 

If a tape file uses standard labels, the iocs determines 
whether an end-of-reel or an end-of-file condition 
exists when the tape mark following the last record on 
a particular reel of that file is sensed. If a tape file does 
not use labels or uses nonstandard labels, the iocs can- 
not perform this function. For this reason the program- 
mer should: (a) specify the dtf ex6addr entry (for in- 
put files), (b) write a routine (whose label appears as 
the operand of the dtf ex6addr entry) which will deter- 
mine whether an end-of-reel or an end-of-file condition 
exists, (c) write this routine so that it will cause a 
branch to be taken to the instruction at iocsrentry if an 
end-of-reel condition exists, or to the first instruction of 
the relevant user-written end-of-file routine if an end- 
of-file condition exists. 

EX7ADDR 

This exit permits the programmer to branch to his own 
routine which will perform additional checking of 
standard input header labels and/or additional input 
header labels or nonstandard input header labels. 

The programmer using Exits 1 through 7 may not use 
any iocs macro-instructions in his own subroutine ex- 
cept the rtlbl, wtlbl, consl, and ( under certain con- 
ditions) iorwu macro-instructions. (For a description 
of the use of iorwu in exits 3 and 7, refer to "Invalid 
Tape Routines" in the section "Additional Information 
for Programmers.") 

EX8ADDR 

This exit permits the programmer to ignore the end-of- 
reel reflective spot, and write additional records. In the 
programmer's Exit 8 routine a switch should be set and 
a branch executed to iocsrentry. This switch should be 
tested in the user's main-line program following the put 
to that file. If the switch is on, the user may include 
additional records on the file. The feorl macro-instruc- 
tion should then be executed and the switch reset. 

VARBUILD 

The varbuild entry enables the programmer to build 
variable-length records in the output area. The operand 
of the varbuild entry is the label of a five-position area 
in storage reserved by the programmer. 

Before building the record, the programmer must 
place the length of the record into the area defined by 
the varbuild operand. He then issues the put filename 
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macro-instruction. The iocs will then insert the high- 
order address of the area into which the record will be 
moved by the programmer into the area specified by 
the dtf varbuild entry. 

The label provided by the user may designate an 
index register. 

The iocs will not accumulate hash totals, but the 
programmer is free to do so. The label of the file hash 
total field is iocscutht, where c is the number of the 
channel ( 1 or 2 ) , and u is the number of the tape unit 
(0-9). 

SCHEDULER 

This special dtf entry may be used to specify a file sub- 
ject to certain restrictions in exchange for a reduction in 
core-storage requirements. 

Records contained on files using this dtf entry cannot 
be processed by means of get, put, or relse macro- 
instructions, and they may be read or written only by 
means of the rtape and wtape macro-instructions. 
open, close, feorl and rdlin macro-instructions may 
be used for such files. 

These restrictions permit use of a small file scheduler 
and consequent savings of 100-750 core-storage loca- 
tions for each file using the dtf scheduler entry. 

Because of the limitations imposed by the reduced 
file scheduler, the following dtf entries may not be used 
for files using the dtf scheduler entry: 

RECFORM INDEXREG 



SIZEREC 


PRIORITY 


PADDING 


WLRADDR 


BLOCKSIZE 


TOTALS 


IOAREAS 


VARBUILD 


WORKAREA 


CARDPOC 



The operand of the dtf scheduler entry is no ( Fig- 
ure 97). 
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Figure 97 

The dtf scheduler entry may be used only for tape 
files. 

Files using reduced file schedulers may be used to 
create or check labels on checkpoint tapes, dump tapes 
or error tapes. 

The scheduler entry has no effect on the way the 
iocs handles end-of-reel and end-of-file conditions. 
They are processed just as they would be if the 
scheduler entry was not used to define the file. 

The programmer may utilize a file using the dtf 
scheduler entry as a work file by modifying the con- 
tents of location iocscutflI, where c indicates the 



channel number ( 1 or 2) and u indicates the tape unit 
number (0-9). The contents of this location should be: 

1 if the tape file is an input file 

if the tape file is an output file 



DA (Define Area) Entries Needed to 
Support the IOCS 

All areas used by the Input/Output Control System 
(i.e., input; output and work areas) must be reserved 
by the programmer by means of appropriate da entries. 
(A general discussion of how da's are written may be 
found in the bulletin, IBM 1410 Autocoder, Form C28- 
0309. ) All such areas must be terminated by a group 
mark with word mark immediately to the right of the 
low-order position of the area. The label of the da entry 
is used to describe the area in the dtf ioareas entry. 

The remainder of this section describes how da en- 
tries are written for the different i/o areas and differ- 
ent types of records. The examples cover input areas, 
output areas and work areas, in that order, and illus- 
trate da's for all types of records which can be handled 
by the 1410 iocs (both with and without indexing, 
whichever is applicable ) . 

Input Areas 

da's for the input areas required by the iocs fall into the 
following four major categories, depending on record 
type and the number of input/output areas: 

1. Unblocked records using only one i/o area 

2. Unblocked (fixed- or variable-length) records 
using two i/o areas 

3. Blocked, fixed-length records 

4. Blocked, variable-length records 

These major categories and their subdivisions are dis- 
cussed below. 

unblocked records using only one i/o area 

For data read in the move mode, see Figure 98. The 
label of the da is used to describe the area in the dtf 
ioareas entry. The 1x80 operand in Figure 98 indicates 
that one area of 80 locations is to be reserved. The G 
operand indicates that a group mark with word mark is 
to be placed one position to the right of the entire area 
defined by the da. 
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For data read in the load mode, see Figure 99. The 
labels of these da areas must not be used as operands 
of macro-instructions. 
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Figure 99 



UNBLOCKED ( FIXED- OR VARIABLE-LENGTH ) RECORDS 
USING TWO I/O AREAS 

With indexing, for data read in the move mode, see 
Figure 100. 



Line 
3 5 


Label 
6 15 


Operation 
16 20 


21 25 30 35 40 ( 


0,i, 


A.RfAt. ! . , . 


D.A, . , 


l.X.Z0.i t X.2.,,0., t 6. . / 


2 


F./.e.L.o.il 










1>S. . . , 




























0,3 


/ c ,/,£ r ,/.,P 1 2 










6,;.i,*rf, . . 




























0,4. 


^\/.«\*-.0.ji 










ij.,.is. , 




























0,5, 


| 






































0,6, 


A.R.E.AJ. t 






QA 




l.X9.4.>6. 




























0,7, 


..... i 










i.i.5, , . . 




























0.8. 


.. . , . i 










6.>.lj. . . 


























\ 


0.9. 


I 










i.U.l.S . 


























i 


'.0. 


. i . i i i 




































( 



Figure 100 

Note 1 : The X2 operand in Figure 100 indicates that 
the labels of the fields and subfields entered under this 
da entry, when referred to in symbolic instructions, are 
indexed by index register 2. 

Note 2: The operand indicates that storage assign- 
ment of fields and subfields entered under this da 
header line is to be relative to zero. 

With indexing, for data read in the load mode, see 
Figure 101. The areaI and area2 labels of these da's 
are the names used to describe these areas in the dtf 
ioareas entry. 



Line 
3 5 


Label 

6 15 


Operation 
16 20 


21 25 30 35 40 \ 


0, 1, 


1 
A.R.e.A.1. i , , . 


D.A. . , 


i.x.9.d,9.x.2.>,di.6 ( 


0.2 


F, /.£",/.. 2>.l! , . , 








5 .,. . 


























0,3. 


^. /,£>./>. 2i , , . 








1.4. . . . 


























0,4, 


F./.E,L,0.3\ . , , 








IS. . . . 


























0,5, 


! 


































0.6, 


AA.E.A.JL. I . , . 


DA 






l.X .9.4,9*6 
























'•) 


0,7. 


„i.,_i,, i„,.i_..i _.L„j.._i — j- 
































.( 



Figure 101 

Without indexing, in either move or load mode 
(processing is done in a work area), see Figure 102. 
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Figure 102 



BLOCKED, FIXED-LENGTH RECORDS 



With indexing, for data read in the move mode, see Fig- 
ure 103. With indexing, for data read in the load mode, 
see Figure 104. Without indexing, for data read in 
either the move or load mode (processing is done in a 
work area), see Figure 105. 
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Figure 103 
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Figure 104 
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Figure 105 

BLOCKED, VARIABLE-LENGTH RECORDS. 

With indexing, for data read in the load mode, see Fig- 
ure 106. (Indexing is not available for move mode.) 
Without indexing, for data read in the move mode 
(processing is done in a work area), see Figure 107. 

Note: The 1, 1 entries are needed by the iocs. 

Without indexing, for data read in the load mode, 
see Figure 108. 
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UNBLOCKED ( FIXED- OR VARIABLE-LENGTH ) RECORDS 
USING TWO I/O AREAS 

With indexing, for data written in either the move or 
load mode (the programmer can build records in the 
output area), see Figure 110. The fields indicated in the 
da are needed only if the programmer refers to these 
records in the output area. Word marks and labels are 
needed only if the programmer does processing in the 
output area or builds records in the output area. 
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Output Areas 

da's for iocs output areas fall into the following four 
major categories, depending on record type and the 
number of input/output areas: 

1. Unblocked records using only one input/output 
area 

2. Unblocked (fixed- or variable-length) records 
using two input/output areas 

3. Blocked, fixed-length records 

4. Blocked, variable-length records 

These major categories and their subdivisions are dis- 
cussed below. 

unblocked records using only one input/output 

AREA 

For data written in either the move or load mode ( the 
programmer can construct records in the output area), 
see Figure 109. The fields indicated in the da are needed 
only if the programmer refers to records in the output 
area. Word marks and labels are needed only if the 
programmer does processing (or builds records) in the 
output area. 
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Figure 110 

Without indexing, for data written in either the move 
or load mode (the programmer cannot construct rec- 
ords in the output area), see Figure 111. The program- 
mer may not use any fields in the output area. 
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blocked, fixed-length records 

With indexing, for data written in either the move or 
load mode ( the programmer can build records in the 
output area ) , see Figure 112. 
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Figure 112 

Without indexing, for data written in either the move 
or load mode (the programmer cannot build records in 
the output area ) , see Figure 113. 



o 



o 



40 



Line 
3 5 


Label 

6 15 


Operation 
16 20 


21 25 30 35 40 1 


0_J_L_ 


AA.FA1. ! . , . 


DA . , 


1.6x.l.1.i.*.uG. \ 


0,2 


AA&AA. ! , , , 


DA . , 


l.4.X*l.1 t 3,*.1j£> ( 


0,3, 


! 




{ 



Figure 113 

The records of Figures 112 and 113 are 80 characters 
in length, including the record mark. When hash totals 
are to be taken, the high-order word mark for the hash 
total field must be included in the das for this type of 
file. 

BLOCKED, VARIABLE-LENGTH RECORDS, WITHOUT INDEXING 

Without the dtf varbuild entry, for data which is writ- 
ten in either the move or load mode ( the programmer 
cannot build records in the output area), see Figure 
114. The 1, 1 entries are needed by the iocs. 
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Figure 114 

With the dtf varbuild entry, where the varbuild 
entry does not designate an index register: for data writ- 
ten in either the move or load mode, see Figure 115. 
The 1, 1 entry is needed by the iocs. The programmer 
may not specify any fields or word marks in the output 
area. When building records in the output area, the 
programmer must use A-field control for all moves, and 
he must generate all his addresses from the record 
address placed in the varbuild location. 
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With the dtf varbuild entry, where the varbuild 
entry designates an index register: for data written in 
either the move or load mode, see Figure 116. 

By letting the varbuild entry designate an index 
register, the programmer can enter in the da all the 
fields needed for the building of records in the output 
area. All moves must use A-field control. The 1, 1 entry 
is needed by the iocs. The X2 entry is used as the dtf 
varbuild entry. The file does not use a dtf indexreg 
entry. 
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Figure 116 

Work Areas 

For data moved in the load mode, see Figure 117. For 
data moved in the move mode, see Figure 118. The 
labels of the work areas are used in the dtf workarea 
entries and as operands of the get to workarea macro- 
instructions. 



Line 
3 5 


Label 

6 15 


Operation 
16 20 


21 25 30 35 40 I 


i,. 


LABEL. 1 , 


DA , , 


1*.8.<4.1.6 J 


2 
3 


f/,a l o,i , 




* \ 


ei E L..DX , , 




i.rf I 


0,4 


FJ £L03\ . , , 




is S 


0,5, 


,,.,.!.., 


, , i . 


...( 



Figure 117 



Line 
3 5 


Label 

6 15 


Operation 
16 20 


21 25 30 35 40 j 


<LJ.l 


LA.BZ.L. ! . , , 


DA . , 


ixe.0.3.6 ( 


0,2 


F/.£,L,D.l\ , , , 




1>.S. \ 


0,3, 


f./,e.l,da\ . , . 




6.-.I.* ( 


0,4, 


F.'.E.i-.Ojl . . , 




l.l.f.1.5. ) 


0,5, 


! , , 


, i i 


i 



Figure 115 



Figure 118 



Use of the 1410 IOCS 41 



—H 1 



Additional Information for Programmers 



o 



This section contains additional information for pro- 
grammers. Subjects covered include error treatment, 
header label checking, record addition and deletion, 
iocs core-storage and timing considerations, file tables, 
diagnostic messages, and unit-record i/o instructions. 

Error Treatment 

COMPOSITION OF THE ERROR ROUTINE 

The iocs error routines for a particular program are gen- 
erated by the Autocoder Processor during assembly of 
the object program, iocs error routines provide com- 
plete error checking for all input/output devices speci- 
fied in the diocs entries. Based on these entries, the 
error routine will be generated for one or two channels, 
for non-overlap or for overlap-priority processing. 

REACTION TO ERRORS 

Errors are brought to the operator s attention by means 
of appropriate error messages printed out on the console 
printer. Certain conditions cause the iocs to enter a 
waiting loop to enable the operator either to ignore the 
error or to take corrective action. Read and write com- 
mands are retried 20 times on data check indications 
before an error message is typed out. Read commands 
aretretried nine times on wrong-length-record indica- 
tions before an error message is typed out. 

data check on last card of file 

If a DATA CHECK occurs on the last card of an input 
card file, the card is not processed; when the IOCS 
tries to re-read the card, the end-of-file routine for the 
reader is entered. To read the card, the operator 
should check the accuracy and registration of the 
punching on the card, put the card in the hopper, set 
EOF, push START, push INQUIRY REQUEST, and 
then push INQUIRY RELEASE. If there is no further 
DATA CHECK, the card will be processed. 

Invalid Tapes 

User-written routines entered from tape label exits 3 
or 7 can be used to reject invalid tapes as follows: (a) 
the current header label is tested; (b) if the current 
tape is valid, a branch is taken to iocsrentry; ( c) if the 
current tape is not valid it is unloaded (iorwu) and a 
message is printed on the coiisole typewriter (consl) 
that informs the operator an invalid tape has been 
mounted; (d) the address referred to by the name of 
the relevant file is placed in index register 15 by a zero 



and add instruction (za -f filename,x15) and a branch 
is taken to iocsentab. The branch to iocsentab causes 
the iocs to read the header label of the tape the operator 
has substituted for the invalid tape. 

When control is returned to the main line of the using 
program, index register 15 is reset (i.e., the contents of 
X15 at the time the branch was executed to the user's 
label routine are restored to X15 ) . 

Record Additions and Deletions 

Records which were not contained on an input file but 
were created in a work area can be moved to an output 
file by the (Format A) put macro-instruction. Input 
records may be omitted from output files by omitting 
the put macro-instruction which would have placed 
these records into the output file. 

Size of the IOCS Routines 

The amount of storage required by the iocs routines 
varies considerably with the number and type of diocs 
and dtf entries written for the object program. The in- 
formation below, however, can guide the user in esti- 
mating the iocs core-storage requirements for various 
object programs. 

WITH PROCESSING OVERLAP AND PRIORITY SPECIAL 
FEATURES 

1. The Priority Assignment Routine: 500 positions of 
core storage. See the diocs priority entry. 

2. Routines Based on the diocs entries: 
Maximum: 5000 

n: 500 

rement with standard labels: 4000 
ement with nonstandard labels: 2800 
Based on the dtf entries (File Sched- 



Mi v - 

Norn 

Normal i \ 
3. Routm 
ulers): 
Maximu* 
Minimun 



600 
50 



WITHOUT PROCESSING OVERLAP AND PRIORITY SPECIAL 
FEATURES 

1. Routines Based on the diocs entries: 
Maximum: 4000 

Minimum: 300 
Normal requirement with standard labels: 3200 
Normal requirement with nonstandard labels: 2000 

2. Routines Based on dtf entries (File Schedulers): 
Maximum: 250 

Minimum: 50 
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Operating Times for GET and PUT Macro-Instructions 

The approximate operating times of get and put macro- 
instructions for different record formats are shown in 
Figures 119 and 120. The figures indicate the time re- 
quired for each record, except the first record of each 
block (when the end-of -block read/ write routine is 
entered). 



Record Type and Handling 



Fixed-length or variable-length, 
blocked records 

Logical records remain in input 
area; indexing is used 

Fixed-length or variable length, 
blocked records. 

Logical records are moved to 
work area; indexing is not used 

Fixed-length, blocked records 

Logical records are moved to 
work area; indexing is used 

Variable-length, blocked records 

Logical records are moved to work 
area; indexing is used 



GET Time in Microseconds 



Maximum 


578 




Minimum 


245 




Maximum 


711 + 11 


.3xL 


Minimum 


378+11 


.3x L 


Maximum 


596+11 


.3x L 


Minimum 


263+11 


.3x L 


Maximum 


637+11 


.3x L 


Minimum 


340+11 


.3x L 



Figure 119. Operating Time in Microseconds for get Macro- 
Instructions 



Record Type and Handling 


PUT Time 


n Microseconds 


Fixed-length, blocked records 


Maximum 


578 


Records are built in output 
area; indexing is used 


Minimum 


245 


Fixed-length, blocked records 


Maximum 


596+11.3 x L** 


Records are moved to output 
area; indexing is used 


Minimum 


263+11.3 x L** 


Fixed-length, blocked records 


Maximum 


711 + 11. 3x L** 


Records are moved to output 
area; indexing is not used 


Minimum 


378+11.3 x L** 


Variable-length, blocked 
records 


Maximum 


882 


Records are built in output 
area; indexing is used 


Minimum 


549 


Variable-length, blocked 
records 


Maximum 


790+11.3 x L** 


Records are moved to output 
area; indexing is used 


Minimum 


457+11.3 x L** 


Variable-length, blocked 
records 


Maximum 


905+11.3 x L** 


Records are moved to output 
area; indexing is not used 


Minimum 


572+11.3 x L** 



Figure 120. Time of put Macro-Instructions in Microseconds 

The major (and sometimes the only) factor deter- 
mining the difference between maximum and minimum 
times shown in Figure 120 is the time required to take 
the trailer record and hash total counts. The L shown 
in Figure 120 represents the number of characters in a 
logical record. 



Priority Interrupt Routine Time 

The approximate time in microseconds required by 
different phases of the Priority Interrupt Routine are 
indicated in Figure 121. It is assumed that five files 
have been assigned to the channel on which the priority 
signal occurs and that the second file interrogated by 
the Priority Interrupt Routine is found to have an i/o 
request. The letters in the fifth column of Figure 121 
refer to the corresponding letters in Figure 122. 



Tape File Tables 

The format of an input tape file table is determined by 
the diocs entries supplied by the programmer. For ex- 
ample, the diocs counts entry causes Fields 21 and 22 
(see Figure 123) to be included in the table. 

The file table provides a set of directions which the 
various iocs subroutines interrogate. These directions 
control beginning-of-reel and end-of-reel procedures. 
Count fields and label information fields are also in- 
cluded. The file table may be modified during execution 
of the object program. However, the iocs interrogates 
the table only when it is processing the open, close, 
feorl, and rdlin macro-instructions or handling begin- 
ning-of-reel and end-of-reel conditions. For this reason 
user modications will have no effect unless an open 
macro-instruction is again given to the file in question, 
or an-end-of-reel condition is in effect at the time of the 
modification on the file in question. 

The file table shown contains the maximum possible 
number of fields. The minimum possible table would 
contain Fields 2, 3, 4, 5, 6, 7, 15 and 20. 

'The $ shown in Figure 123 represents iocs; c repre- 
sents channel; u represents unit. 

Field 1: This field contains the operand of the dtf 
priority entry, or the number 9 if the entry was omitted. 
This field will not appear unless the diocs features 
entry containing the overlap and priority operands 
was supplied. 

Field 2: This field contains the number 1 if one i/o 
area was specified in the operand of the dtf ioareas 
entry, or the number 2 if two areas were specified. 

Field 3: This field contains @0b@ if the file is 
opened; it contains @bb@ if the file is closed. This field 
is used by the iocs to determine if the tape must be re- 
positioned if the program is restarted from a checkpoint. 

Field 4: This field contains the Op Code and X-Con- 
trol field of the instruction required to read the base 
tape. If @ or * appear in the hundreds position of the 
X-Control field, the diocs features entry containing the 
overlap and priority operands must be supplied; if % 
or 13 appears, these operands must be omitted. It also 
contains the Op Code of the Branch If Any i/o Channel 
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Status Indicator On instruction used to check for errors 
after execution of the i/o instruction used to read the 
base tape. 

Field 5: This field contains the same information as 
Field 4, except that the information in this field is for 
the alternate tape. 

Field 6: This field contains the address of the file 
initialization sequence. 



Field 7: This field contains the programmer's end-of- 
file routine address for input files, the padding routine 
address for fixed, blocked output files, or the address of 
a location within the iocs end-of-reel routine for all 
other output files. 

Field 8: This field is missing unless the diocs 
labeldef operand was specified with either the mixed 
or the standard operand. 



o 



Phase of Priority Interrupt Routine 


Time 
(Without Read or Write Errors) 


No. 


FROM 


TO 


Conditions 


Line of Coding 
in Fig. 122 


Maximum 


Minimum 


1 


Interrupt of 
Main Routine (A) 


Return to 

Main Routine (F) 


5 Files (See NOTE). 
No input/output 
operation pending 


A-B-C-D'-D-E-F 


1050 


820 


2 


Interrupt of 
Main Routine (A) 


Start of execution 
of Input/Output 
Command (C) 


5 Files; second file 
interrogated has an 
I/O request 


A-B-C-C 


1390 


690 


3 


Interrupt of 
Main Routine (A) 


Return to 

Main Routine (F) 


5 Files; second file 
interrogated has an 
I/O request 


A-B-C-C'-D-E-F 


1920 


1170 



NOTE: Add or subtract 50 microseconds for each file difference from five. Applies to Phase 1 only. 
Figure 121. Approximate Time in Microseconds for Different Phases of the Priority Interrupt Routine 
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Figure 122. Approximate Time Required by Different Phases of the Priority Interrupt Routine 
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Field 


Label 


Mnemonic 


Operand 


1 




DCW 


@9@ 


2 


$cuACT 


DCW 


@2@ 


3 




DCW 


@bb@ 


4 


$cuBASE 


DCW 


@M@U3R@ 


5 




DCW 


@M@U4R@ 


6 




DCW 


$culNIT 


7 


$cuEOF 


DCW 


FILEOFADDR 


8 


ScuFSCK 


DCW 


@o@ 


9 


$cuHFS 


DCW 


@12345-@ 


10 




DCW 


@016b@ 


11 




DC 


@ALPHAXNAME@ 


12 




DC 


@63365@ 


13 




DC 


@-030b@ 


14 


ScuTFLB 


DCW 


@o@ 


15 


ScuTFLl 


DCW 


@1@ 


16 


$cuTFL2 


DCW 


@1@ 


17 


$cuTFL3 


DCW 


@2@ 


18 


$cuTFL4 


DCW 


@0@ 


19 


$cuTFL5 


DCW 


@o@ 


20 


$cuTBC 


DCW 


@bbbbb@ 


21 


$cuTRC 


DCW 


@bbbbbbbbbb@ 


22 


$caTHT 


DCW 


@bbbbbbbbbbbbbbbb@ 


(» 


^PUT) 




(OUTPUT) 


23 


$cuD6 


DCW 


@1@ $cuDl DCW @1@ 


24 




DCW 


EXIT6ADDR DCW EXIT1ADDR 


25 


$cuD7 


DCW 


@1@ $cuD2 DCW @1@ 


26 




DCW 


EXIT7ADDR DCW EXIT2ADDR 


27 






$cuD3 DCW @1@ 


28 






DCW EXIT3ADDR 


29 






$cuD4 DCW @1@ 


30 






DCW EXIT4ADDR 


31 






$cuD5 DCW @1@ 


32 






DCW EXIT5ADDR 


33 






$cuD8 DCW @1@ 


34 






DCW EXIT8ADDR 



Figure 123. Input Tape File, File Table 



For input files this field contains if the operand of 
the dtf checklabel entry supplied was all. This will 
cause the input header label routine to compare the 
header file serial number with the contents of field 9. 
This field contains 1 if the all operand of the dtf 
checklabel entry was omitted. In this case the input 
header routine will not compare the header file serial 
number with the contents of field 9. 

For output files this field contains 1 if the dtf 
serialnum entry was omitted. This will cause the input 
header routine to place the tape serial number in 
field 9 when the file is opened, but before the new 
header label is written. This field contains if the dtf 
serialnum entry was supplied. In this case the reel se- 
quence number is not placed in Field 9. 

Fields 9 through 13: These fields are missing if field 
8 is missing. These fields contain the label information 
shown in Figure 85, positions 11 through 40. The iocs 
uses these fields to prepare output header labels and to 
check input header labels. The dtf header and 
serialnum entries supply this information. If they are 
omitted, these fields contain blanks. 



Field 14: This field is missing if field 8 is missing. 
This field contains if the standard operand of the dtf 
typelabel entry was supplied, 1 if this entry was 
omitted, or 2 if the nonstandard operand was supplied. 

Field 15: This field contains if the dtf filetype en- 
try specified an output file; 1, if an input file. 

Field 16: This field does not appear if the diocs alt- 
drive entry has been omitted. It contains 1 if the dtf 
alttape entry has been specified. It contains if the 
dtf alttape entry has been omitted. 

Field 17: This field is missing if field 8 is missing. 
Furthermore, this field will not appear unless either the 
dtf header and serialnum entries or the diocs labeldef 
entry with the ident operand was supplied. This field 
contains if the dtf checklabel entry with the all 
operand was supplied; 1, if this entry was omitted; 2, 
if the ident operand was supplied. 

Field 18: This field is missing if the tm operand of 
the diocs labeldef entry is omitted. This field contains 
1 if the tm operand of the dtf typelabel entry was 
supplied, or if the tm operand was omitted. 

Field 19: This field does not appear unless the diocs 
rwdoption entry was made. This field contains if the 
norwd operand of the dtf rewind entry was supplied, 
1 if the dtf rewind entry was omitted; 2 if the unload 
operand was supplied. 

Field 20: This field contains the number of blocks 
made available to the user by means of the get macro- 
instruction. Input blocks bypassed by the users wlr 
routine are not included in this count. 

Field 21: This field contains the number of records 
made available by the get macro-instruction or pro- 
cessed by the put macro-instruction. This field appears 
if the record operand of the diocs counts entry was 
supplied. 

Field 22: The hash total is accumulated in this field. 
This field appears if the hash operand of the diocs 
counts entry was supplied. 

Fields 23, 25: For input files, these fields contain 1 if 
the dtf exit6addr and exit7addr entries were supplied, 
or if they were omitted. These fields appear if oper- 
ands 6 and 7 of the diocs exits entry were supplied. 

For output files, these fields contain 1 if the dtf 
exitIaddr and exit2addr entries were supplied; if 
they were omitted. These fields appear if operands 

1 and 2 of the diocs exits entry were supplied. 
Fields 24, 26: For input files, these fields appear if 

operands 6 and 7 of the diocs exits entry were supplied. 
For output files, these fields appear if operands 1 and 

2 of the diocs exits entry were supplied. 

Fields 27, 29, 31, 33: These fields contain 1 if the 
dtf exit3addr, exit4addr, exit5addr, and exit8addr 
entries were supplied, or if they were omitted. These 
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fields appear if operands 3, 4, 5, and 8 of the diocs 
exits entry were supplied. 

Fields 28, 30, 32, 34: These fields appear if operands 
3, 4, 5, and 8 of the diocs exits entry were supplied. 

IOCS Diagnostic Messages 

During assembly, the iocs may generate diagnostic 
messages for errors in the use of the iocs coding entries. 
These messages are printed on the assembly listing and 
on the console typewriter. (Thus, installations employ- 
ing an assemble-and-execute sequence of operation can 
save machine time by not attempting to execute im- 
mediately an object program that will not run. ) 

The format of the iocs diagnostic messages is as fol- 
lows: 

nnn.MACRO.xxx 
nnn is the identification number of the message; macro 
is the name of the macro-instruction in which the cod- 
ing error was made; and xxx are code letters that indi- 
cate the type of error, as follows : 

W (Warning) The program may run as assembled. 
E (Error) The Program cannot run as assembled. 
C (Comment) The program can run as assembled. 
(The iocs writes an explanatory comment when 
this code letter is given. ) 
One of these letters is always given as the first letter of 
xxx. Other code letters of xxx further define the mistake 
that was made in coding the macro-instruction, as fol- 
lows: 

M Operand or specification missing. 
U Unrecognizable or undefined operand. 
A Assumed. (The iocs has assumed, on the basis of 
the diocs and dtf entries, the intent of the pro- 
grammer, and the assembly has proceeded on that 
assumption. ) 
D Deleted. (The iocs has not generated any rou- 
tines or linkages for the macro-instruction. ) 
P The object deck can probably be "patched" (with 
the instruction listed by the iocs whenever it gives 
a message containing this code letter ) . 



O Over call. ( The iocs correlates the diocs, dtf, and 
macro-instruction entries. The overcall code letter 
is given whenever one of these entries is either 
redundant or unnecessary. For example, if a diocs 
labeldef entry is written for the program but 
there are no dtf entries for tape files, the iocs 
assumes that labeldef is an overcall. ) 



User-Coded 1402 and 1403 Input/Output Instructions 

The user may code 1402 Card Read Punch and 1403 
Printer input/output instructions in Autocoder, pro- 
vided the conventions shown in Figure 124 are ob- 
served. 
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Figure 124. 

Any card read punch or printer i/o instruction coded 
in Autocoder may be substituted for the instruction 
shown on line 2. 

bef is only used following card read operations; how- 
ever, it may be omitted. If it is omitted, and if an end-of- 
file condition is sensed by the unit-record error routine, 
the iocs prints the message "10100 nr (i/o op)", issues 
a read-a-card instruction, and enters a waiting loop. 
The waiting loop is terminated by a successful card 
read operation. 

bef need not be addressed to eofaddr; it may, for ex- 
ample, be addressed to the next sequential instruction. 

iosys pause and resume are not necessary unless 
read/write and processing operations are overlapped 
on channel 1. 
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